Winsck: Runtime Error '40006'?

I wrote a chat program using the winsck control. I have noticed that if a client connects and then stays connected for an extended period of time (2+ hours) then the server app. crashes with the following error:
----------------------------------------------------------------------
Runtime Error '40006'

Wrong protocol or connection state for the requested transaction or request.
----------------------------------------------------------------------

Any one have any ideas on how to fix this? Or better yet what Sub would I need to add an 'On Error goto ....' line of code to trap this error?

Thanks!

It sounds like the socket connection may be getting dropped for some reason. Do you check the socket's state prior to any action (such as checking for state = sckConnected before doing a SendData)?

I am pretty sure I do (I don't have the source with me, it's at home). I will take another look and make sure.

The funny thing is that the client thinks it is still connected to the server the entire time. I also noticed that the server only crashes when a client that has been connected for a couple of hours and then tries to disconnect. (When my clients disconnect they send a LogOff message to the server.) I think the message reaches the server otherwise the client would give an error as well.

Is there a place in a program where you can trap all errors (not only in the Subs but overall)? Otherwise I will have to add an Error trap to all of my Subs (something that should have been done as I wrote the program! :)

Thanks....

Without seeing your code, it's hard to say what is happening.

It isn't really necessary for the client to 'logout'. When either side closes the socket, the socket state on the other side will go to sckClosing. If you watch for that, you can then close the socket on that end as well.

Good point! I got so involved in try to figure out how the client(s)/server would communicate I didn't even consider that I didn't need to send the log off! Thanks!

I have another question concerning the winsck control. I noticed that some people predetermine how long the data sent/received will be. I think this is a great idea and will prevent someone from dumping to much info on the server/client. With this in mind how can I do this when I don't know how long each message sent will be? Is there a way to compress/expand a string so that it will meet the size requirement?

Thanks again...

You are writing a chat rogram...I don't see where you need to be concerned with the message length.

I wrote a file transfer app that puts a 52 byte header and as many records as will fit into a 16KB block before sending it. TCP/IP will break it down into smaller packets for transmission and then reassemble it in the correct order at the other end. That is a function of the protocol and will not impact your app.

With all the issues with the buffer overflow problems I was wanting to make sure that I didn't run into the same issue with my winsck control. Does the winsck control limit the amount of data that it can receive at one time or can you overload its buffer?

Each socket will have its own buffer. Do you think someone out there might be able to type fast enough to fill up a buffer;)

Actually it isn't a 'real time' chat room where each character is sent as it is typed. I have a text box that they type there message in and then click a send button. The send button bundles their message together with some additional command parameters and then sends the whole thing to the server. I have limitations on the message text box but that doesn't stop a hacker from finding my port/protocal and then sending his/her own oversized message to the socket. The only thing I could do to prevent this is to make sure they can't overflow the socket buffer (if that is possible). Is there anyway to make sure that this doesn't happen?

I don't know what limitations MS may have placed on the buffer size, so I can't elaborate there.

The winsock control does not give you any control over the socket session. It is a simple to use packaging of the sockets api. You would have more control if you were to switch to the api.

One thing to consider is the possibility of rejecting certain connections. Are the clients connecting from known IP addresses? If so, after accepting the connect request, you could check the remosthost against the known list and close the connection if the IP is not in the list.