Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.os.linux.development.apps > #395
| 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> |
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 | Next — Previous in thread | Next 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