PT Forum

Dale Schultz 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 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 Joined: 1st Nov 2021
Location: Maine, USA

Posted: 19th Nov 2021 17:27

I'll try and see if somehow closing one socket add nuls to other sockets...

Indeed this is happening.

Here is the code:

+ Code Snippet

if  listenerID &gt; zero
			
			if SocketId &lt; one // no connection
				socketID = GetSocketListenerConnection( listenerID )
			else // already connected
				// are there more connections?
				i  = GetSocketListenerConnection( listenerID ) 
if i = socketID  // added this check temporarily to confirm that we are not getting a duplicate ID, and we dont.
	addlog ("Dup socket ID obtained:" + str(i))
endif					
				if i &gt; zero // another connection
					Command as string
					j as integer
					command ="{NAME}" + cName + chr(13) + "{MSG}Already connected to " + GetSocketRemoteIP(socketID ) + chr(13)+ "{BYE}" + chr(13)
					for j = one to len(Command) + one
						SendSocketByte( i, asc(mid(Command,j,one)) )
					next j
					FlushSocket(i)
					addlog ("Rejected connection from:" + GetSocketRemoteIP(i))
					deletesocket(i)
					
				endif
			endif	
		
		else
			SetupListener()
		endif // listenerID

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 Joined: 1st Nov 2021
Location: Maine, USA

Posted: 19th Nov 2021 18:56

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 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 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!

<1 >

Sign In