>> As I mentioned before, TCP is a stream protocol, not a message >> protocol, so when you expect to receive all data before sending >> another request over the same TCP socket, that is plain *wrong*, >> though some people here appear to think this is possible. > > How would any interactive TCP protocol such as ssh be usable if what you say > were true for most people's setup? Even the good old ESMTP and POP3 protocols > depend on the command-response messages being received within a reasonable > time.
Ah, yeah, correct. Granted, I exaggerated. To answer your question: there's two ways: one is by disabling Nagle for your TCP connection (setsockopt(TCP_NODELAY)) so that your write()/send() data is passed through the stack and onto the hardware line immediately. That's standard for telnet and other interactive protocols which ride on top of TCP. No delays whatsoever; drawback is more network packets which may contain just a few application data bytes. Default TCP stack behaviour is to wait for more data to be passed down by the application through socket write()/send() when the previous amount was 'too small' (which depends on your stack's configuration parameters). That 'waiting for more to be sent' is disabled by the TCP_NODELAY option. Which leaves us 'solution' number 2 if we don't want to disable Nagle: wait for the timeout to happen as it will 'flush' the remaining send data onto the line. IIRC it's somewhere in the neighbourhood of 200 .. 500 ms, so for a single request-response it's certainly within 'reasonable time' limits. SMTP/NNTP/... don't usually disable Nagle and there you see that timeout happen ever so often when a request was sent and the client is waiting for another 2xx (or other) response. (... checked the books here to make sure I didn't completely screw up: See W. Richard Stevens TCP/IP Illustrated Vol. 1, section 19.4, Nagle algorithm, pp. 267-273; WRS mentions 200ms there, BTW. See also same book (Vol.1), chapter 28: SMTP, pp. 441 a.o., where the network message trace at page 444 shows the ~200 ms timeouts for each exchange. Further info in TCP/IP Illustrated Vol.2: TCP_NODELAY, pp858 and Appendix C, RFC1122 compliance, pp1120, where it says the delay before data to sent is flushed must be < 0.5 seconds. All in all, perfectly reasonable timing. What I forgot to mention is that when you don't know this and you are transferring 'web pages' across persistent HTTP (TCP) connections, those timeouts are going to hit you relatively bad when you have pages which a constructed from several URLs (say 1 html page, 1 CSS file, 1 JavaScript and maybe 10 images: grand total of 13 requests. Worst case time _loss_ due to TCP send timeouts: (13-1)*(<0.5) (let's assume it's 200 ms everywhere) = 12*0.2 = 2.4 seconds delay: no data is transfered during that period as the HTTP server TCP stack is 'waiting for more to come'. Of course, that's worse case, so in practice the delay due to this particular reason alone will be lower for such pages, but when you have graphic intensive (= lots of tiny icons and stuff) pages which are loaded using only one or two 'persistent' sockets (most browsers limit the number of parallel connections to site X), user experience is going to hurt. There, 'reasonable' is not 'reasonable' anymore. While no-one is going to sit and wait out an SMTP exchange, so those .2 seconds per request are perfectly okay there. (All of this does not apply to telnet & co. as those 'interactive protocols' have TCP_NODELAY turned on on each transmit side, so zero time lost twiddling thumbs waiting for the user/application to send()/write() any more data.) All the above does not consider the added (possibly also buffering) SSL layer; I have not taken the time to verify that code again to see if it may or will add additional delays in either reception or transmission of small amounts of data due to clustering of transmitted data (similar to what Nagle does for TCP). The only thing I am certain about there is that OpenSSL offers a specific API for turning off Nagle on socket BIOs: BIO_set_tcp_ndelay() in bio/b_sock.c -- which I have used in the past to successfully create 'interactive communication' applications over SSL/TCP. If I screwed up in there or am otherwise saying wrong stuff, please correct me. It is appreciated. Your remark made me verify my own 'off the top of my head' data, which is always a good thing. -- 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 Development Mailing List [email protected] Automated List Manager [EMAIL PROTECTED]
