Error thinking of a AS3 socket decoding design

Debugging a game is really a torture job. No wonder many people in the industry like to say "good game is changed out." Chidu (game.qdooo.com) Foundation platform is currently testing, Lu continued to receive a lot of friends feedback (want to participate in testing friends Welcome to contact me to request Activation code). So the main work in this period of time is to do landscaping and optimization, the new competitive system is also in the busy preparation.

Here I want to talk about the socket decoding in the design of a problem neglected. (Thanks for Lite3 's feedback).

The basic reading method for the client socket is generally divided into three types:

1, according to the end of the data flow interception
2, according to the packet length of Baotou Records interception
3, according to the packet length intercept and verify the end tag.

The first way: as shown in the figure, usually the hair is sent at the end of each packet to send a token, indicating that the packet sent out. The socket is read 1 bytes at a time until the end character is encountered, and the end read passes the packet to the logical layer. This approach has been used a lot in xmlsocket.

The second way: the length of the complete package is recorded in the header with an integral type. Each time a packet length is read, and then the specified length of data is read as a complete packet to the logical layer, according to the packet length.

The third way: figure. This method combines the above two methods, read the time without one byte read, directly read the specified length. The end character can be used to make a checksum decision and can be read as a packet length byte. (If the last package has a problem to discard, read the packet length of the next package with a trailing sign.) ）

Introduced a little basic principle, the following is the design flaw.

Problem:

In communication we use the second way-packet length read. Create a temporary storage variable _dataarray in the communication class, providing a GetData ():* public method for externally fetching data. Press into _dataarray each time a full package is read, triggering the "Recieveddata" event. The code is as follows:

Private Function Socketdatahandler (event:progressevent): void
{
_readflag:int;//0 said all finished, 1 for length read 2 indicates reading data
while (bytesavailable)
{
if (_readflag = = 0&&bytesavailable>=4)
{
_length = number (ReadInt ());
_readflag=1
}
if (_readflag = = 1 && bytesavailable >= _length)
{
var temp:object = ReadObject ();
_dataarray.push (temp);
Dispatchevent (New Event ("Recieveddata"));
_length = 0;
_readflag = 0;
}
}
}

The code above is structurally not a problem, and we've been using it without any problems in the early stages of the test. The logic is quite clear: after receiving an event for the socket, read the packet length first and then read the data according to Baochang. Read out event ...

Then, the problem finally came-the Netizen Lite3 appeared. ^ _ ^

Lite3 sent an error message:
Error:error #1502: The execution time of the script has exceeded the default timeout setting of 15 seconds.
At Qdooo.net::mysocket/socketdatahandler ()

I believe you can see where the problem is--the problem is on the while.

The while loop wait time has exceeded 15 seconds for some reason. This refers to a certain reason is the speed, that day Lite3 that the Internet is very slow. This magnifies the impact of a flaw in the design-it must wait until the length of the readable data is equal to or greater than the length of the packet to begin reading, which is the following sentence:

if (_readflag = = 1 && bytesavailable >= _length)

It is because of this judgment that, if the data is not long enough, then he will wait in the while loop. No more than 15 seconds of error.

Solve:

Analysis of the reasons for good so very well solved, to find ways to read the data inside the flow let while jump out waiting on the line.