Re: The "Reconnect" Problem
- From: Scott Gifford <sgifford@xxxxxxxxxxxxxxxx>
- Date: Wed, 23 Jan 2008 13:19:09 -0500
Michael B Allen <miallen@xxxxxxxxxx> writes:
[...]
Let's say I'm writing a networking client and I would like to multiplex
requests over the same connection. Everything works great and it's
all very efficient but when the connection gets dropped for whatever
reason (e.g. I pull the network cable out of the computer) and I want to
reconnect transparently, there is a tendency for the code to get caught
in an endless loop of disconnect and connect ops.
I solved a similar problem with this approach:
The connection is managed in a dedicated thread. This thread tries to
connect when a connection is desired, and when it is connected
processes a queue of pending requests to be sent. When the connection
is up a second thread sits in a blocking read on the connected socket.
Clients that want to send messages put them into a queue. The
connection thread will wake up when there is a message in the queue,
try to connect if necessary, then send the message. Clients can
register callbacks to handle incoming data, and to be notified when
their message has been succesfully sent.
So the API becomes "send", which enqueues a message to be sent,
connecting if necessary and retrying if necessary; and
"register_recv_callback" which registers a callback to handle incoming
messages.
Hope this helps,
----Scott.
.
- References:
- The "Reconnect" Problem
- From: Michael B Allen
- The "Reconnect" Problem
- Prev by Date: Re: Patent status of Proxy Collector?
- Next by Date: Re: creating thread in C++
- Previous by thread: Re: The "Reconnect" Problem
- Next by thread: Suggestions for server architecture
- Index(es):
Relevant Pages
|
