Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.development.apps > #394
| From | Rainer Weikusat <rweikusat@mssgmbh.com> |
|---|---|
| Newsgroups | comp.os.linux.development.apps |
| Subject | Re: long lasting client socket connection |
| Date | 2012-01-14 00:49 +0000 |
| Message-ID | <87mx9rhzvc.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> <20120113141314.101@kylheku.com> |
Kaz Kylheku <kaz@kylheku.com> writes: [...] >> 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. But it can't do that. For realtime communication, TCP has a problem called 'head-of-line blocking': The first reply the server tried to send will arrive before all other replies: Either the client is happy with receiving replies to its requests within the time limits of 'the TCP'. Then, it should just block in read until the reply was received or the connection is aborted (which may never happen). Or, replies become stale aka 'useless' after some time has passed. And in this case, the TCP connection used to send the request which went stale cannot be used to receive replies to more current requests in time anymore. [...] > Because you're using a reliable stream protocol, ... you should be downloading a file from some background process. Otherwise, you are using the wrong protocol.
Back to comp.os.linux.development.apps | Previous | Next — Previous in thread | Find similar
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