Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.development.apps > #393

Re: long lasting client socket connection

Show all headers | View raw

On 2012-01-13, Bill M <wpmccormick@just_about_everywhere.com> wrote:
> Rainer Weikusat wrote, On 1/13/2012 8:54 AM:
>> Kaz Kylheku<kaz@kylheku.com>  writes:
>>> On 2012-01-12, Bill M<wpmccormick@just_about_everywhere.com>  wrote:
>>>> I'm working on a socket client app that makes a connection to a server
>>>> and leaves it open. Thinking that since he's repeatedly asking
>>>> questions, there's little point in wasting time closing and reopening
>>>> again. Are there any good design patterns out there for this I should
>>>> take a look at?
>>
>> [...]
>>
>>> But seriously, noe thing you have to watch out for is keeping such connections
>>> idle for too long. It's almost impossible to avoid such an application being
>>> deployed by someone in a scenario where the client connets trhough one (or
>>> more) NAT gateways to the server. When these routers don't see any activity
>>> between a pair of destinations, they will expire the mapping entry, and then
>>> your connection is gone.
>>
>> The same is true for any kind of stateful firewall even if NAT
>> isn't being used (and people use NAT quite mindlessly because "that's
>> how it is always being done). If you want to keep a TCP connection
>> open, you have to include application layer keepalives (preferably
>> using a randomized interval) and application-transparent (disconnect
>> and) reconnect (and restart sending of what was supposed to be sent
>> by the time the problem was detected[*].
>>
>> [*] You only have to when you want this to work reliably. That's
>> something the guy who committed hibernate considered to be 'an
>> optional feature', consequently, his orm framework doesn't do that by
>> default but nobody ever didn't get a job with RedHat just because of
>> publishing 'designed by a retarded, typing monkey' open source
>> software ...
>>
>
> The client application is multi-threaded; each thread makes a socket 
> connection and keeps it open. Client threads continuously send requests 
> to the server, and then wait for a pthread condition when the reply 
> (terminated with \n) comes in, or it time times out.

There is already a dedicated socket and a dedicated thread, yet
the dedicated client thread has to wait for yet /another/ thread to
bang the condition variable?  Sounds screwy.

(Or you mean that the client API for sending a request submits the
request, and then waits for the client thread to receive the reply
and hit the condition variable?)

> A problem occurred when a client actually timed-out and the data came in 
> right after that, so then the next client that sent a request got the 
> reply for the previous, and so on from that point on. (The client 
> supplies the read buffer.)

What you have to do is unambiguously identify the requests with a request ID
and have the replies carry a matching request ID. 

The client should wait not just for any reply, but for a reply with a
particular ID.

The reply coming in with the previous ID will be discarded. Ideally the socket
thread knows that there is a new request waiting for a new ID, and can just
toss the old reply away.

Because you're using a reliable stream protocol, the ID's don't actually have
to go into the protocol. But you locally have to match requests with replies
somehow.

Suppose that ten rapid requests are made, with very short timeouts, and they
all fail with a timeout. Then another request is made. The thread should know
that this is request #11, so it can throw away the replies for the requests
1 through 10 which were sent out to the server.

> I was just wondering if 1) the basic concept of leaving sockets 
> connected was flawed and 2) if maybe anybody out there has done anything 

Timing out such that you leave the flow of replies in an ambiguous
state is flawed.

Back to comp.os.linux.development.apps | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

long lasting client socket connection Bill M <wpmccormick@just_about_everywhere.com> - 2012-01-12 16:04 -0600
  Re: long lasting client socket connection Kaz Kylheku <kaz@kylheku.com> - 2012-01-12 22:21 +0000
    Re: long lasting client socket connection Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-01-13 14:54 +0000
      Re: long lasting client socket connection Bill M <wpmccormick@just_about_everywhere.com> - 2012-01-13 15:58 -0600
        Re: long lasting client socket connection Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-01-13 22:17 +0000
          Re: long lasting client socket connection Bill M <wpmccormick@just_about_everywhere.com> - 2012-01-14 14:43 -0600
        Re: long lasting client socket connection Kaz Kylheku <kaz@kylheku.com> - 2012-01-13 22:38 +0000
          Re: long lasting client socket connection Rainer Weikusat <rweikusat@mssgmbh.com> - 2012-01-14 00:49 +0000

csiph-web