   Winsock TCP Server / Flash MX 2004 XMLSocket Issue
  I have coded up a TCP app in C++ that will act as the server for a number of Flash MX 2004 clients, using XMLSocket. A brief overview of XMLSocket is a TCP-based connection in Flash that can send XML (or simple character strings) followed by a null byte. There is no support for UDP in Flash so TCP was all I could use.The server seems to be working very well. It has the ability to buffer incoming messages and process them as needed. It also supports blocking and non-blocking i/o modes.I am having a problem with Flash making two consecutive calls to XMLSocket.send(). Although I have confirmed with a simple Perl server that two messages are indeed being sent each and every time, my C++ server almost always refuses to process the second message. I would say maybe 1 time in 20 it will acknowledge that two seperate XML messages were sent to it. My feeling is the problem is with the server here. I have tried to disable Nagle on the socket, when a new client connects, but this doesn''t seem to affect whether or not the second messages gets in. I suppose there is the possibility I am not disabling Nagle at the proper time in my code but I doubt it (pretty much happens right after accept()).One caveat: If I set a breakpoint in Flash, and physically halt the code execution after the first call to XMLSocket.send(), wait a moment, and then step to the next call to XMLSocket.send(), the C++ server receives both XML messages and processes them as if there is no problem whatsoever. 100% of the time, absolutely reproducible.Can anybody think of any additional checks I should be making, possibly with or without Nagle enabled or disabled, in order to try to figure this out? I am pulling my hair out over it. I feel like that there are many differnet WSA-related options/functions in Winsock that I just have no idea where to start.- Hanzo 
  Nagels affects the outgoing messages, not the incomming messages, you''ll have to disable nagels on the client side. Flash proably doesnt let you do that, since the socket is so insulated under the XML layer, you will need to do something like the equavialent of a flush call on the client side. Either peroidic heart beats messages on the client to the server, to get the stream moving, or if there is an explicit flush command in flashes api.Good Luck.-ddn ;  My feeling on why I still believe it is the server (and that the server can be made to work to with Flash) is simply that all other servers that I have tested with (Perl, Java, etc) work flawlessly each and every time they receive multiple sends from Flash. There must be some combination of Winsock settings that will allow this bizarre receive mechanism.I tried the heartbeat method and it failed. It continued to send heartbeats every second, yet my message #2 of my original set still didn''t show up.I suppose I could go to a single message methodology and just have a maxsize buffer that is read in each and every time (inefficient as hell) but can''t seem to find any way around this strange and frustrating issue. ;  Its difficult to speculate without seeing any source code for the server but your buffering of received data is one place to check.You are using variable length messages terminated by null characters. Since you don't know in advance the length of a particular message and are using TCP, you will have to buffer what data you do get until a full message has arrived.Could it be you are reading in messages back to back but throwing away the second since it does not arrive in 2 separate recv()s? Something like:// message looprecvData(messageBuffer)if (messageAvailable(messageBuffer)) // error! should be while (messageAvailable))  processMessage(messageBuffer);  EDIT: It may be easier to use blocking i/o with fixed message lengths until the server logic is working correctly.   [edited by - jermz on February 5, 2004 6:00:45 PM];  Do you deal properly with the fact that you may receive the end of one message and the beginning of the next message in the same TCP read call? TCP is a stream protocol, it does not know about or enforce any "message boundaries" manually. ;  After reading several posts, and rethinking my plan, I reformatted my xml message structure to prepend the bytesize to each message, and then read in only that much of the message each time. The server now works as planned. Each call to recv only handles as many bytes as are dictated in the first four bytes of the xml message, properly seperating messages as originally planned.- Hanzo 