João Távora wrote: > Given a NDA forbids me from giving you more details let me give you > an analogy with postal services: I assume you know of postal services > where you can get a delivery receipt. you can get a receipt that the > recipient was notified, if the postman gets shot along the way, the > postal service will send more postman. If they run out of postmen I > get a receipt stating the delivery was impossible.
Yes, that's because the postal service implements a delivery receipt that is passed to the next layer up. > In many situations, like the state wanting you to appear in court to > testify, all it needs is one such little receipt of notification. If > you fail to appear in court, that's your problem. > It's completely OK and encouraged for applications to rely on services > provided to them by inferior layers. Yes, provided those services are in fact provided by the inferior layers. > When writing a TCP application I > don't need to look inside the TCP layer for acnowledgement > information, I just get an errno set in my next "write()" call which > will say "connection reset, broke or anything". You may get an errno set in the your next write call. You may not. This is explicitly not guaranteed. A success in your next write call again just means your data was queued and no errors were yet detected. > And, my little Schwartz-friend. don't bother with more pedantic > metaphysical considerations about my "misunderstandings" and > "nonsenses". I'm sorry about the original quote from wikipedia if > that's what pissed you off. I'm not pissed off. I'm simply trying to correct a misunderstanding you have (or had) about TCP ACKs. A TCP ACK does not tell higher-level protocols that data was received by the application on the other end. TCP ACKS are a TCP-to-TCP thing. TCP does not assume that an ACK means application delivery. SSL does not assume a TCP ACK means this because it doesn't. So there is no way to forge TCP ACKs and create a problem for SSL. TCP doesn't even have any way to report that data was received by the other end at all (except perhaps during connection teardown, but that introduces its own wrinkles due to the two generals problem). DS ______________________________________________________________________ OpenSSL Project http://www.openssl.org User Support Mailing List openssl-users@openssl.org Automated List Manager majord...@openssl.org
