Question : tcp keepalive protocol

The tcp keepalive function is specified in RFC 1122 section 4.2.3.6.  However, it does not specify how to implement keepalives!

From searching I've found references to zero data length data segment or a segment with a garbage data byte.

I need information of what a keepalive packet/probe looks like and what to send back.  

I need specifics down to the bit level.

References to RFCs, STDs, URLs can be used to keep the entry readable.

Thanks!

JGT

Answer : tcp keepalive protocol

I'm still not clear on what your trying to accomplish and I'm not a programmer myself so I'm going to try to nudge you in a direction I think might be productive for you but without being clear on the objective, the means available to accomplish that objective or the timeframe to accomplish the task I'm fairly blind so this might become a bit of blind-leading-blind, but bear with me a bit as I try to respond to your questions

1 - "What are the major keep alives"
This is where we are the least clear, the place I'm most used to dealing with keep alive is with network connectivity equipment (obviously) such as VPN bridgeheads and DSL modems or computer-based routers. I assume that we are somewhere in that ballpark and your looking for what a keep-alive message from major manufacturer's equipment would look like (I. E. Linksys DSL router, Watchguard VPN equipment or Cisco PIX equipment) What I would suggest you do is a little experimentation. Since a short answer is not forthcomming from the community I'd suggest you connect your computer to a hub, connect the piece of equipment you wish to see the keep alive from to that same hub and then run a network sniffer on the PC to monitor all TCP datagrams traveling through the hub, at which point you will see what the keep alive message looks like as it leaves the piece of equipment.

2 - "What do they look like"

I don't honestly know. I've configured the equipment but never gotten to the nitty-gritty of packet monitoring. I can quote PennGwynn for you though and say they look like a payload-less TCP/IP packet ; ) I'd say that your best bet is definately to break out a network monitor (netmon is included with windows 2000 server for instance, many other products are available as well) and analyze what is going on in your specific environment.

3 - "What is the proper response for each."

If you set up the hub and monitor an existing network you'll see the keepalive from the eqiupment and the replies. I don't know if this is possible but i would hope you could setup the piece of equipment your trying to get to talk to your OS to talk to something else and then eavesdrop on that conversation to get the details on what your OS should be saying and isn't and then resolve the deficiency.

Chris