Hi All. I guess all my theories are bang on, as the entire framework was integrated seamlessly making use of the above "theories". Thanks a ton to everyone, and extra thanks to Viktor ? Thanks and Regards, Ajay On 10 Oct 2016 6:34 a.m., "Ajay Garg" <ajaygargnsit at gmail.com> wrote: > Thanks Michael for the reply. > > And yes, your points are absolutely valid. > > We do not assume anything at the client/server as such, we just read > the byte-streams, and generate (MQTT) packets out of bytestreams as > and when the starting- and ending- boundaries of a (new) MQTT-packet > are received. > > > Still, I believe all my 3 questions (step a, step b, and the 8-point > story in step c) are independent of this, and would like to hear from > you experts as to if my understanding of all those 3 steps is correct, > including the all important assumption > > *Implicit in this workflow is my assumption that SSL too builds up a > packet for every BIO_write done over "bio1". * > > I say it the most important, because our application is MQTT-based, > and all our communication is request/response based; we send a packet, > and expect an acknowledgement. > > In other words, if my implicit assumption is correct, then every > "BIO_write(bio1)" would generate a complete SSL-packet, which would be > available at "bio2" instantly and synchronously - ready to be > transferred over the wire. > > > Again, would be thankful from the bottom of my heart, to hear > confirmations/rejections regarding my theories in step a), step b) and > 8-point-story in step c) as per my previous email. > > > > Thanks and Regards, > Ajay > > On Mon, Oct 10, 2016 at 2:39 AM, Michael Wojcik > <Michael.Wojcik at microfocus.com> wrote: > >> From: openssl-users [mailto:openssl-users-bounces at openssl.org] On > Behalf > >> Of Ajay Garg > >> Sent: Sunday, October 09, 2016 14:12 > >> > >> Also, for all my cases, Nagle's algorithm has been disabled on the > >> client as well as the server, so every write (at client/server) > >> constitutes a packet-transferred. > > > > This assumption is incorrect. Nagle is not the only factor which > interferes with a 1-to-1 mapping between application sends and (IP) packets > on the wire. The peer's receive window, the interface and path MTUs, > fragmentation, transient network failures ... many things can either split > an application message into multiple IP packets or even multiple TCP > segments, or cause multiple application messages to be coalesced into a > single TCP segment (which usually is also a single IP packet, now that path > MTU determination usually works properly). > > > > You should never assume TCP is anything other than a byte-stream > service. An application that makes any assumptions about how its send > operations translate into TCP segments or IP packets is asking for trouble. > > > > -- > > Michael Wojcik > > Distinguished Engineer, Micro Focus > > > > > > > > -- > > openssl-users mailing list > > To unsubscribe: https://mta.openssl.org/mailman/listinfo/openssl-users > > > > -- > Regards, > Ajay > -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://mta.openssl.org/pipermail/openssl-users/attachments/20161010/795673ff/attachment.html>
