I have a server app built in Xojo and a client program written in Java. The Xojo server uses a ServerSocket and a TcpSocket. The ServerSocket uses addsocket like this:
Return New SckTCP
TcpSocket uses DataAvailable like this:
[code]
Dim strIn as String
Dim strOut as String
strIn = me.ReadAll
'Tried setting an EOT char and receiving chunks instead didn’t help
'Dim intEOT As Integer = Instr(Me.LookAhead, strEOT)
'Do Until intEOT = 0
'strIn = me.Read(intEOT)
'strIn = strIn.ReplaceAll( strEOT, “”)
'intEOT = Instr(me.LookAhead, strEOT)
'Loop
strOut = ProcessInput(strIn)
me.Write strOut + EndOfLine
’ Tried closing and not closing here didn’t help
'if me.BytesLeftToSend = 0 then
me.Close
end[/code]
The client app initiates the connection, sends a message, and then using a timer every X seconds it sends an update message to the server once connected.
I’m running into a problem where if two client apps hit the server at relatively the same time and connect the first time, when they try to update via the timer on the same interval, I get a connection reset by the peer error on the client(java) side and then even though the client tries to reconnect it can’t until I restart the client app.
I could really use some advice on how to fix this issue. I’ve tried a few different things already, you’ll see commented in the code above.
I can’t see any way to tell the TcpSocket to ‘keep-alive’ on the Xojo side. I get a 102 message after each message is returned from the Xojo socket even when I am not closing it.
Any ideas on what is causing my issue or how to fix it or any best practice advice would be greatly appreciated! Thanks!
You might not get all your data in one “readall”. You should rather add what is read to a string until you are sure you have your “EOT” marker or whatever, maybe checking in a timer. Then send the reply, and only close the socket after the sendcomplete.
Edit - and close the socket outside of the socket ( way back all kinds of hell could break loose - maybe things have changed.)
@Peter Job I tried that it didn’t work. It’s nothing to do with the how I am handling the message input, it has something to do with the socket being open or closed. Thanks though.
@Peter Job Well I agree, I’ve seen this post on here, but the Xojo sockets sends a 102 after each message it returns to the client app. I believe that means it closes the connection. I tried a keep-alive request from the client side but the 102 event still fires after the Xojo socket returns the response. Thanks for your help.
@Peter Job that part of the above code is commented out. I didn’t start closing the socket until I was trying to find a way to resolve the issue. I get the 102 event after the socket returns the message even if I don’t close the socket manually on the Xojo side.
I was really hoping someone that understands how the TcpSocket handles the connection and it’s underlying pool of connections could explain to me how that works so I could maybe understand what is happening. It almost seems like my client app is trying to communicate with a previously open ‘but now closed’ socket reference. @Tim Hare @Norman Palardy
@Norman Palardy Ok that’s useful but the error I am getting on the client side says the connection has been reset by the peer, which is the Xojo socket. Believe me, I HAVE looked on the client side at length, that’s why I am in here looking for some ideas.
I would love some insight Norman if you could have a look at what I am doing here to understand what is failing.
The client initiates a connection to the Xojo socket, sends a message, receives a response, and then disconnects. If I close the socket or leave it open on the client side either or, I’ve tried both, the Xojo socket 102 event happens. This is ok.
My problem is that on the attempt to reconnect let’s say 30 seconds later, if two clients try to reconnect at roughly the same time give or take a second or two, one of them will fail to connect to the Xojo socket, and I receive a socket reset by peer error on the client side. No connection is logged on the xojo side from that client, and no matter how long after this, I still cannot establish a connection to the xojo socket from the client that failed until I manually restart the client.
I’m trying to understand this behavior from the xojo socket. Any ideas?
@Wayne Golding I have it set to default, which it looks like is creating 10 TCPSockets when the AddSocket event fires in the ServerSocket. It seems to create more though as it needs them. I’m not against trying to adjust this and doing some tests if you think that would help.
Try setting the max to 32 & the min to 8. I’m getting a maximum sockets connected value of 1 without setting these parameters. With 8 minimum you should get 18 sockets created. Let us know how you go.
@Wayne Golding that indeed appears to have resolved this issue!!! THANKS!!!
Now my question is if I am assuming there may be let’s say 50 or more clients connecting at any given time, maybe all at once how should I adjust these min and max numbers so that there are always available sockets? I don’t trust what this code tells me in the AddSocket event of the ServerSocket anymore…
You can monitor the number of active connections for the socket using .activeconnections.ubound. I would suggest you set a reasonable number for max then monitor the active connection levels with each new connection (addsocket event handler). You can always increase that during runtime if you get too close the maximum.
The minimum level is needed on a busy server to ensure there are enough available sockets in the pool. My investigation shows that initially a pool of the minimum + 10 sockets will be created when 11 sockets have been consumed another pool of 10 will be added (been a while since I investigated this though). I guess you could get 102 errors if the available pool ran out during busy times regardless of the maximum connections parameter. If you are paranoid you could set the minimum available to maximum connections.
