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


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

Re: long lasting client socket connection

Path csiph.com!x330-a1.tempe.blueboxinc.net!usenet.pasdenom.info!weretis.net!feeder1.news.weretis.net!news-peer.in.tum.de!fu-berlin.de!uni-berlin.de!individual.net!not-for-mail
From Rainer Weikusat <rweikusat@mssgmbh.com>
Newsgroups comp.os.linux.development.apps
Subject Re: long lasting client socket connection
Date Fri, 13 Jan 2012 22:17:11 +0000
Lines 26
Message-ID <87ty3zgsd4.fsf@sapphire.mobileactivedefense.com> (permalink)
References <jenlde$i5v$1@dont-email.me> <20120112141650.885@kylheku.com> <87sjjjirem.fsf@sapphire.mobileactivedefense.com> <jeq9eg$pb0$1@dont-email.me>
Mime-Version 1.0
Content-Type text/plain; charset=us-ascii
X-Trace individual.net 868k4mB7KLFQQgbuq9e+ewJGfYx1XoocEZpKL7y9SL6rUTpJk=
Cancel-Lock sha1:Cp5pfXqNwi6+Mew4TZkiXpF5keQ= sha1:VmkJ2QDGyyiZ7nDKcx9FeDGnUg4=
User-Agent Gnus/5.11 (Gnus v5.11) Emacs/22.2 (gnu/linux)
Xref x330-a1.tempe.blueboxinc.net comp.os.linux.development.apps:392

Show key headers only | View raw


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.

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.

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