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 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> References: <20120112141650.885@kylheku.com> <87sjjjirem.fsf@sapphire.mobileactivedefense.com> 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 Bill M 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.