Keep sockets alive when connection is broken

Hi,

I have the following issue: I'm using sockets with SSLStream and want to keep the sockets active when an IOException is thrown on a BeginWrite for example. Let's say a client is connected to a server and the client tries a BeginWrite on the ssl network stream and just in that moment the internet connection goes down and an IOException is thrown with a result of the socket being disconnected. Is it possible to "RESUME" this connection on the very same port after the internet connection is reestablished

My client/server works over the internet and I need a guarantee that the client received every message the server sent. So I give every message that is being sent a sequence number. If the sequence numbers have a gap, the client asks the server to resend the missing messages. However, to get this work I need to be able to work with the same sockets even after they threw exceptions, so I can properly reestablish the connection and ask the state object that has the messages in cache to resend them.

Anybody has some advice on this

Thanks,

Tom

Answer this question

Keep sockets alive when connection is broken

YoungJoe

Well firstly if the TCP connection is not sending data and the network goes down then the connection will not be affected. If it is however in the process of sending data and the network breaks (apparent because the expected acknowledgment packet(s) are not being recevied) then TCP will retry a number of times and finally it will give up and close the connection. This will result in a SocketException, and if a NetworkStream is being used, then that exception will be caught and wrapped in an IOException before being thrown to the user program.

The default setting for number of retries is five in Windows XP and earlier (I haven't checked whether the new TCP/IP stack in Vista behaves differently), and the TCP/IP protocol always uses a exponential backoff algorithm such that it waits double the time for each successive retry. So say that TCP has decided based on previous responses to initially retry after 0.5 seconds, it will thus do: s 0.5 r 1.0 r 2.0 r 4.0 r 8.0 r 16, where 's' is the initial send, and 'r' is a retried send, thus waiting 31.5 seconds before breaking the connection and letting the user know of the problems.

Once a connection is closed it obviously cannot be reused.
Erik BN
Another question I have is, what if some central internet routers have some issues and the tcp message can't be delivered, will I get an IOException as well If so, when (Note, I'm talking about async sockets, not sync where Send/Receive timeout is an option)
naguaramipana
Hi, can anybody give an answer to these questions.

Thanks
Koray Samsun

One an exception is thrown, socket is disconnected and there is no way to keep it alive. you have to reconnect it to server and there is no guarentee that what port it will use... but I don't think this all can become a hurdle in your messaging system...

What i have understood that server application must have to identify the clients and communicate with them using those message sequences.

For example:

Client1 > Server (Connected)

Client1 > Server (Message Sq#1) Ok

Client1 (Message Sq#2) > Server Gone (Conection Broker)

Client1 > Server (Connected) Reconnection.

Client1 < Server Send Sq#2 (Send Sq#2)

Here you can see that server knows what last sq# was and it will query +` from the client... But it has to ask this sq# number from Client1 only not client 2 because Client2 has some other sq# at the moement....

How Will you identify the Cleints

When a client socket is connected to server socket you can use its Remote EndPoint property to see from which IP Address it has conencted (It means you have identified the clients and you have to continue your broker communication from the same point where it was lost.)

For better solution you can use usernames........ to be authenticated on server end after connection and then proceed. (Think you have more than one clients connecting from the same client machine) so here for identificaion of the client you can use usernames. One other solution is Digital Signatures...... but i think usernames are quiet enogh if security is not a serious isssue in your solution.

Need more help

Please feel free to write back here or by email.

Best regards and best of Luck.

Rizwan aka RizwanSharp
Selimbd

Any update

Best Regards,

Rizwan aka RizwanSharp
Keep sockets alive when connection is broken

Answer this question