TCPSocket sometimes receives constant stream of 0x00

I’ve seen this on and off over the years but never in any way I’ve ever been able to duplicate on demand. I’ve had it happen several times lately though in my own testing and I’m completely at a loss as to how or why it’s happening.

Whats happening is that once in a blue moon I’ll 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 don’t know? That feedback report is at <> 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 I’ve never had it happen then, but that might not be real, it might just be a timing thing since it’s so rare to happen anyway.

The specific setup I’ve 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. It’s not possible to use the stdin/out streams as it’s 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 I’m not actually sending nulls in a loop down the socket from the client app after connection, there isn’t any code that I can imagine could do that. It’s 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 don’t come in immediately during the open event but it’s 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 <> 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.
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 you’re right, it’s not sending that is the problem, it’s 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 :wink:

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 think I found where 8 K is set and have asked other engineers for comments / feedback on some questions I have

SSL Users blocks and we also saw things coming in blocks, too

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

Let me say I have spent some time spelunking around and I have some hunches that I’ll check out with the other engineers when they are in Monday

But they ARE just hunches

i hope you can fathom how much I appreciate your spelunking :slight_smile: fruitful or not!

Sadly it doesnt suggest to me anything about why you get a stream of nuls creating things in the event

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?

thats not a bad idea, I will install some of that so when it happens again I can see if it’s “real” traffic or not.

See also my case 32231: <>

We had to make our own encryption layer for speed.