Ive seen this on and off over the years but never in any way Ive ever been able to duplicate on demand. Ive had it happen several times lately though in my own testing and Im completely at a loss as to how or why its happening.
Whats happening is that once in a blue moon Ill receive a socket connection which connects and then the data available event on the receiving side just starts firing as fast as it can. Performing a readAll returns you an entire buffer full of null characters. These are server sockets so the buffer size is limited to 8192 bytes which is a separate problem, or maybe a related problem I dont know? That feedback report is at <https://xojo.com/issue/41046> and should be on the radar for anyone using server sockets to send more than 8k of data in a single write as it will be MUCH slower than it should be.
I THINK that this only ever happens when the sockets are setup and opened immediately at app launch. If I close the socket and re-open it Ive never had it happen then, but that might not be real, it might just be a timing thing since its so rare to happen anyway.
The specific setup Ive got is a console app also written in Xojo is launched in a shell from the main program and then connects via a TCP socket. Its not possible to use the stdin/out streams as its binary data and they choke on nulls, or at least they used to in the distant past.
Once the null stream starts happening the connection is basically dead, the dataAvaliable event will continue to fire as fast as it can hanging up your program. I have verified as well as I can that Im not actually sending nulls in a loop down the socket from the client app after connection, there isnt any code that I can imagine could do that. Its got to be something about the timing of the connection during the launch of an app. In the open event of the main app the serverSocket is setup and set to listen, and then the shells are created and the helper apps launched. So the incoming connections dont come in immediately during the open event but its still fairly close in some cases.
Has anyone ever seen anything like that or have any insight into what might be causing such a thing?
[quote=329634:@James Sentman] That feedback report is at <https://xojo.com/issue/41046> and should be on the radar for anyone using server sockets to send more than 8k of data in a single write as it will be MUCH slower than it should be.
[/quote]
Being pedantic here but server sockets themselves do not send or receive data
They hand all communications off to an instance and the instances have this 8K limit
That said what happens if instead of opening the socket in the open event its once the open event is done
ie/ set up a one shot timer in the open event that executes in 1msec and THAT times action event starts the server socket and so creates all instances that way ?
TCPSockets created individually do not have the 8k limit, only those handed off through a ServerSocket. But youre right, its not sending that is the problem, its receiving data. The biggest block you can get in a dataAvailable event in a TCP socket handled through a ServerSocket is 8k, so you have to wait whatever the main loop time is before you can get another 8k, even if a hundred k or more would have been passed in a non-ServerSocket related TCP socket.
But besides the point
I am gearing up now actually to move the starting of the server and the forking off of the shells to a slightly delayed event.
I wonder if the sockets just dont get serviced frequently enough or something as a socket created by using it with a server socket isn’t, AFAICT, created differently than one NOT being used with a server socket
Have you tried running packet capture on the machine to see if there really is traffic to go along with the streams of nulls, and if so, where they originate?
fruitful or not!