Re: Sockets in C on Linux
From: Randy Howard (randyhoward_at_FOOverizonBAR.net)
Date: 02/03/05
- Next message: RACFacilitator: "Re: internet fraud by rentacoder.com"
- Previous message: Programmer Dude: "Re: Which new language to learn?"
- In reply to: Andrea Sini: "Re: Sockets in C on Linux"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Thu, 03 Feb 2005 21:07:36 GMT
In article <ggoMd.490243$b5.23126729@news3.tin.it>, do@notwrite.it says...
> Michael Jørgensen wrote:
> > Use the socket options SO_KEEPALIVE and TCP_KEEPALIVE.
>
> First of all, thanks for the answer.
>
> I'm working with a Mandrake Linux Distribution and I wasn't able to use
> the option TCP_KEEPALIVE because it isn't defined were I suppose it
> should be, that is in netinet/tcp.h
>
> Are there other files to look for it ?
TCP_KEEPALIVE is a relatively new POSIX option, which allows the timeout
interval to be set for each connection, but it is not implemented
everywhere. Relying upon it will invoke the evil queen of unportability.
It won't solve your problem anyway, if I understand the original question.
You (at the application level) need to know if the "other end" has gone
away, but for some you reason you don't want to generate any traffic
to find out. You may find that the best way to solve this is to use
a heartbeat mechanism to make sure the connection is good, even during
otherwise idle time (on the wire). The keepalive feature is usually
not useful to applications, the TCP stack sends a message, the peer
responds with an ACK, but, *the app does not get notified that the
exchange took place*. So, it doesn't help you know for sure.
It isn't exactly what you *want*, but it may be what you *need*.
Jon C. Snader has a very thorough coverage of this common (but rarely
understood) problem in his excellent book, "Effective TCP/IP
Programming", Addison-Wesley, 2000. If you really want to understand
TCP, I highly recommend you buy a copy and read it front to back.
Of course, any of the Stevens books are excellent as well, but for
"get the biggest improvement in the shortest time" approach, I
think Snader's book is very good, plus it has a lot of working
examples.
-- Randy Howard (2reply remove FOOBAR) "Making it hard to do stupid things often makes it hard to do smart ones too." -- Andrew Koenig
- Next message: RACFacilitator: "Re: internet fraud by rentacoder.com"
- Previous message: Programmer Dude: "Re: Which new language to learn?"
- In reply to: Andrea Sini: "Re: Sockets in C on Linux"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
