First of all: heed David's [Schwartz] advice, especially in his last email.
This stuff is /not/ meant to fix broken designs but only to be used when you absolutely have to: what you can use, when you need to detect clients crashing or networks failing, is add a 'heartbeat' (as was mentioned before by David Richardson) to your TCP peer to peer connections, so you will get an error message from your TCP/IP when the 'heartbeat' stops, i.e. the communication path has broken down somewhere (in a cable, a router, a switch or the client failing itself (power cycle or some other causes). You don't need special connections on the side for this, as TCP offers a method for this: the SO_KEEPALIVE socket option. It's not precisely standard, but all boxes I have been using, UNIXes, Linux, Windows, and several embedded TCP/IP stacks, all offer this one. They don't have to, though. Before you run off shouting Yowza!, here's what W. Richard Stevens (R.I.P.) has to say about it in one of his highly regarded books (TCP/IP Illutrated Vol. 1, 1994, Ch.23, pp. 331-337): "Keepalives are not part of the TCP specification. The Host Requirements RFC provides three reasons not to use them: (1) they can cause perfectly good connections to be dropped during transient failures, (2) they consume unnecessary bandwidth, and (3) they cost money on an internet that charges by the packet. Nevertheless, many implementations provide the keep-alive timer." Written in 1994, it is still 100% valid. Read the entire chapter before you run off and say you solved matters. By the way: grep the OpenSSL code to see it in use: BIO_s_connect() delivers a socket connection with the KEEPALIVE heartbeat turned on (unless your system does not support such an option) and, in the case of SSL, this choice makes sense. That means that (1) OpenSSL client-side connections created through the use of BIO_s_connect() will have this option active from the very start; (2) it also means the OpenSSL /client/ sets this option, while you say you need it server-side, which means you'll have to do it yourself at socket BIO level (but that's easy; the hard part is making sure your process goals /require/ a design which includes this 'server-side initiated heartbeat' as a mandatory element, and can't live without it). I can't emphasize enough you should not jump to gun (pointy-haired people come to mind ;-) ) and at least read Stevens' chapter on this. Mark his words regarding fiddling with this timer. (It has nothing to do with SSL, it's TCP protocol level stuff below that.) Because heartbeats (and thus keepalive timers) are an area just /begging/ you to screw it all up. And it may not even bother you, but there's significant risk it'll bother quite a few other folks along your network paths, including your clients themselves. At the end, I'm still wondering if I should have written this, as it makes it way too easy to 'just do it' and this bit requires /thought/, particularly at protocol design level, not just a simple line of code and 'presto!' (And for those that are google-trigger happy: I'm sure 'keepalive' will give you many, many hits. It's (almost?) all about a completely different animal: HTTP KeepAlive. Which is a cute, cuddly fellow living in an entirely unrelated, far off biotope.) -- Met vriendelijke groeten / Best regards, Ger Hobbelt -------------------------------------------------- web: http://www.hobbelt.com/ http://www.hebbut.net/ mail: [EMAIL PROTECTED] mobile: +31-6-11 120 978 -------------------------------------------------- ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager [EMAIL PROTECTED]
