Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

AppGameKit Classic Chat / extra nul being placed in TCPIP buffer every 60s

Author
Message
Dale Schultz
3
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 19th Nov 2021 16:48
My app maintains a TCPIP connection with other software. I use SendSocketByte() to send data.

My system sends and receives commands over this connection. When there is no traffic I send my own ping command so I can track if the connection is lost for any reason.

I have noticed that when there is no traffic and I send my ping every 10 seconds, every 6th command arrives at the other end with an addition zero byte (hex zero).
If I send my ping command every 20 seconds then, yup, every third one has the spurious nul byte.

I suspect that AppGameKit has decided to add a nul byte to TCP connections every 60 seconds. (Perhaps for its own ping system, which would be fine to do if you control both ends).

Can anyone confirm that this is true?

Is so, this is nasty. Is there any way to clear the outgoing buffer before sending proper content?
Dale Schultz
3
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 19th Nov 2021 17:07
well, perhaps not (thankfully)

I found that another computer on the network was making a connection attempt to my phone running the AppGameKit code, and once I stopped that from happing the extra nuls went away.

But the additional connections should be independent, using separate sockets (which are also deleted after rejecting additional requests).

I'll try and see if somehow closing one socket add nuls to other sockets...
Dale Schultz
3
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 19th Nov 2021 17:27
Quote: "I'll try and see if somehow closing one socket add nuls to other sockets..."

Indeed this is happening.

Here is the code:



Here is my log window on the AppGameKit app showing the results that get logged:


Note we get no message stating we got a duplicate socket ID
After the second connection was rejected, the other side of the first connection reported that the next {PING} command had a spurious nul byte

Unless anyone can explain why working with a second socket should add a nul byte to a first socket, I'll write this up as bug.




Dale Schultz
3
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 19th Nov 2021 18:56 Edited at: 19th Nov 2021 20:09
gah! it get even worse.. it appears that in addition to the spurious nul byte that gets into the buffer right away after rejecting a second connection, another one gets there some seconds later.

I added code to try and purge the bad byte right after rejecting additional connections, and that works (in a fashion) but then the next commands that is sent is also corrupted with a leading nul...
Dale Schultz
3
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 19th Nov 2021 19:34
sending two commands after rejecting the second connection seems to clear extraneous nul bytes.
Thereafter no extra bytes are encountered (until the next rejected connection)

The commands in the yellow box were sent to purge the buffer, and both resulted in unrecognized commands due to the nul bytes.
(Note since this is asynchronous, the logging of the commands being sent does not always match the arrival of the error message from the other side)

Thereafter commands go through fine, until another connection request is rejected.
Dale Schultz
3
Years of Service
User Offline
Joined: 1st Nov 2021
Location: Maine, USA
Posted: 19th Nov 2021 20:08
whatever process is writing nulls to the socket is doing it very soon after the other connection is closed and deleted.
If I delay sending the data very slightly, only one command is need to flush the junk instead of two.
The delay is just the time needed to call a function to do it instead of doing it inline!

Login to post a reply

Server time is: 2024-11-23 08:12:03
Your offset time is: 2024-11-23 08:12:03