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


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

Re: long lasting client socket connection

From Bill M <wpmccormick@just_about_everywhere.com>
Newsgroups comp.os.linux.development.apps
Subject Re: long lasting client socket connection
Date 2012-01-14 14:43 -0600
Organization A noiseless patient Spider
Message-ID <jespeg$p40$1@dont-email.me> (permalink)
References <jenlde$i5v$1@dont-email.me> <20120112141650.885@kylheku.com> <87sjjjirem.fsf@sapphire.mobileactivedefense.com> <jeq9eg$pb0$1@dont-email.me> <87ty3zgsd4.fsf@sapphire.mobileactivedefense.com>

Show all headers | View raw


Rainer Weikusat wrote, On 1/13/2012 4:17 PM:
> Bill M<wpmccormick@just_about_everywhere.com>  writes:
>
> [...]
>
>> 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.
>>
>> 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.)
>
> As stated, this is not possible: If each client uses a connection of
> its own, no client can ever receive a reply for another client.

I think this is the key comment. I need to re-think my design. Looking 
at things again, what I really have is a single client thread that 
multiple (other) threads are sharing. I need to re-code this so that 
each thread actually has it's own client. I'm trying to do this with 
code from a generic client object (that I also wrote). I need to figure 
out how to code this so that each client thread get's it's own copy of 
things like a file descriptor, sockaddr_in, and client state in general.


>
> Apart from that: If you think you need application level timeouts with
> TCP then you need to destroy and recreate the connection after a
> timeout occurred: Otherwise, you will either get all replies in the
> order they were sent no matter if the client still wants them or not
> or a transport layer connection abort after 'a long time'. TCP isn't
> (and isn't designed to be) suitable for communication with realtime
> requirements. Consider using UDP, possibly with a suitable
> retransmission scheme.
>

Given that each client "send" expects a reply, and that the "sends" are 
continuous, the I still think a connected TCP socket is the right way to 
do this. I just need to code it so that if a client attempts to send and 
errors occur before the reply is received, then the existing connection 
is torn down; a new one is built; and the send is attempted again.

Thanks!!

Back to comp.os.linux.development.apps | Previous | NextPrevious 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