> From: owner-openssl-us...@openssl.org On Behalf Of Fekete, Tamás (lesswire AG Ungarn) > Sent: Saturday, 17 March, 2012 01:03
> But I am thinking, maybe a trivial question to you. > Do I need use something "to ACK" messages? Maybe. It depends on your application(s). SSL/TLS, like TCP which it is designed to partly replace, is (stream-oriented and) only conditionally reliable -- IF the data is delivered it will be correct (in-sequence, not duplicated, not altered including insert or delete) but it may be delayed arbitrarily long, and a suffix may be lost entirely (albeit with an indication for >=3.0 IIRC). > As I know lower layers treat ACK and if something went wrong > I receive error message during the sending yet. Is it true, is not? At the SSL/TLS protocol level there is no explicit ack or flow control of data. (There are some implicit acks in the handshake protocol.) SSL/TLS just passes data down to TCP which should get it there. TCP does have acks, but not synchronous; a send call can and often does return 'successfully' before all of the data has been actually sent on the wire, or _any_ of it has been received. If the data isn't acked 'soon' by the receiving stack, according to various rules/heuristics, the sender stack will retry, and if it still gets no ack after some number of retries, or if it gets an explicit down indication (RST or various ICMP), it will return an error to the caller on the *next* send *or recv* call. (Here TCP returns the error to OpenSSL, which in turn returns it to the application.) Moreover, even if the receiving TCP stack acks some data, that doesn't mean the receiving *application* got the data, much less processed it successfully. > And in this way if I implemented ACK mechanism > into my protocol it would be useless. If you need an application level ack, it is not useless. > Or maybe do you know such kind of situation where > it can be useful? Because in that case if I find one situation > I let it in my code, but in other hand I remove that. Generally if there is any importance to the transmission of data additional to the content of the response if any, consider ack-ing. A common and relatively understandable example is HTTP (commonly used over both SSL/TLS and TCP). If you send a request and get back a page*, or an HTTP error like 404, you know the request was received and processed. If you get a disconnect before/without any HTTP response, you don't know what happened, but often you can just retry the same request on a new connection. Some requests, often POSTs, shouldn't be retried because that might result, for example, in making two payments when you intended only one. If the processing of the request takes a long time, during which an interruption leaves the status of the request "in doubt", you might issue an interim (dummy) response that says "I got request X and am processing it, check later for results" and then use a GET with a unique id to check for and (eventually) get the results, with (safe) retries if needed. However, there will always be some window, even if you make it shorter, where a transaction/request/whatever is in doubt, and must be resolved by some other means. This is inherent in nearly all distributed protocols and is generically called the "last-ack" problem. And it is true even for any ack's you put in your application protocol, so think about how your users can/will deal with problem cases. * Technically any resource, not necessarily a webpage; but in my experience requests that get non-HTML resources are always(?) idempotent i.e. safely retriable. ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
