I use a lot socket and be sure that SOCKET_DATA event is ALWAYS dispatched.
It happens to me too, on TWO Windows Vista 64bit machines.
Something isn't stable - a few small (few bytes) packets being sent from the server in high frequency (coming out from a loop in the server for example).
Now usually the client raises
Once or twice but then the packets are stuck in the "queue".
Very weird behaviour.
Hi, has anyone discovered what is happening with this? I am having the same problem and also happen to be on a Vista 64bit system.
I am able to reproduce the problem quite easily for anyone that already has a server loop set up and is sending messages to their flash client.
In your flash SocketData handler function, just add a long loop, something like this:
private function onSocketData (e:ProgressEvent):void
var count:int = 0;
while (count < 1000*1000)
The problem that I seem to be getting, is that in the time it takes my handler function to process the data, new data has arrived from my server loop (keeps sending messages super fast). It seems the new data is either getting queued up (although if it is, it's not being given to me in the order it arrives) or that the data is just being ignored/lost.
Does anyone have any insight on this?
I've added a delay of 100ms to the server loop and everything works fine, but this is definately not a long term solution and I've only done so to check if it is in fact the Flash side that's really buggered.
Come to think of it, I'll try making my flash side extremely fast by simply dispatching a new event on the socketdata handler and see if those events get queued and/or lost/destroyed.
Ok, sound I found what the 'problem' is.
By doing a trace on the sockets bytesAvailable, I can see that multiple messages that come too fast are combined into one big data array and so I get one big ProgressEvent in my flash socketDataHandler function.
So for myself, all of my packets were size 23 bytes containing specific data. I noticed however, that if I got two really close together, the size of the bytesAvailable to my socket was 46 bytes and that both datapackets had been merged into one single one.
So my suggestion to anyone having the same problem is to mark all of your packets with what type it is as the first byte(s), then how long the remaining data is with the second byte(s).
This way, when your messages get crammed together, you can read the first message since you know how many bytes to expect, and the remaining bytes must be part of the next message. This also works if your message gets split between socket calls.
Anyhow, sorry about the clarity, I've rushed this post due to sleep.