4 Replies Latest reply on Nov 3, 2009 9:47 PM by Big_Stink

    Socket ProgressEvent.SOCKET_DATA

    paravoice
      I'm in trouble now.
      see flash.net.Socket
      My question:
      If the data being transmitted is very small or it happens very quickly, does ProgressEvent.SOCKET_DATA event might not be dispatched?

      Why I ask like this?
      Because, see flash.net.FileReference's ProgressEvent.PROGRESS event:
      In some cases, progress events are not received. For example, when the file being transmitted is very small or the upload or download happens very quickly a progress event might not be dispatched.

      thanks very much.
        • 1. Re: Socket ProgressEvent.SOCKET_DATA
          jylaxx Level 1
          I use a lot socket and be sure that SOCKET_DATA event is ALWAYS dispatched.
          • 2. Re: Socket ProgressEvent.SOCKET_DATA
            Lopo Nopo

            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

              ProgressEvent.SOCKET_DATA

            Once or twice but then the packets are stuck in the "queue".

             

            Very weird behaviour.

            • 3. Re: Socket ProgressEvent.SOCKET_DATA
              Big_Stink

              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)

                   {

                        count++;

                   }        

              }

               

               

              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.

              • 4. Re: Socket ProgressEvent.SOCKET_DATA
                Big_Stink Level 1

                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.