<p dir="ltr">Hi All.</p>
<p dir="ltr">I guess all my theories are bang on, as the entire framework was integrated seamlessly making use of the above "theories".<br></p>
<p dir="ltr">Thanks a ton to everyone, and extra thanks to Viktor ðŸ˜Š</p>
<p dir="ltr">Thanks and Regards,<br>
Ajay</p>
<div class="gmail_extra"><br><div class="gmail_quote">On 10 Oct 2016 6:34 a.m., "Ajay Garg" <<a href="mailto:ajaygargnsit@gmail.com">ajaygargnsit@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Thanks Michael for the reply.<br>
<br>
And yes, your points are absolutely valid.<br>
<br>
We do not assume anything at the client/server as such, we just read<br>
the byte-streams, and generate (MQTT) packets out of bytestreams as<br>
and when the starting- and ending- boundaries of a (new) MQTT-packet<br>
are received.<br>
<br>
<br>
Still, I believe all my 3 questions (step a, step b, and the 8-point<br>
story in step c) are independent of this, and would like to hear from<br>
you experts as to if my understanding of all those 3 steps is correct,<br>
including the all important assumption<br>
<br>
*Implicit in this workflow is my assumption that SSL too builds up a<br>
packet for every BIO_write done over "bio1". *<br>
<br>
I say it the most important, because our application is MQTT-based,<br>
and all our communication is request/response based; we send a packet,<br>
and expect an acknowledgement.<br>
<br>
In other words, if my implicit assumption is correct, then every<br>
"BIO_write(bio1)" would generate a complete SSL-packet, which would be<br>
available at "bio2" instantly and synchronously - ready to be<br>
transferred over the wire.<br>
<br>
<br>
Again, would be thankful from the bottom of my heart, to hear<br>
confirmations/rejections regarding my theories in step a), step b) and<br>
8-point-story in step c) as per my previous email.<br>
<br>
<br>
<br>
Thanks and Regards,<br>
Ajay<br>
<br>
On Mon, Oct 10, 2016 at 2:39 AM, Michael Wojcik<br>
<<a href="mailto:Michael.Wojcik@microfocus.com">Michael.Wojcik@microfocus.com</a><wbr>> wrote:<br>
>> From: openssl-users [mailto:<a href="mailto:openssl-users-bounces@openssl.org">openssl-users-bounces@<wbr>openssl.org</a>] On Behalf<br>
>> Of Ajay Garg<br>
>> Sent: Sunday, October 09, 2016 14:12<br>
>><br>
>> Also, for all my cases, Nagle's algorithm has been disabled on the<br>
>> client as well as the server, so every write (at client/server)<br>
>> constitutes a packet-transferred.<br>
><br>
> 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).<br>
><br>
> 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.<br>
><br>
> --<br>
> Michael Wojcik<br>
> Distinguished Engineer, Micro Focus<br>
><br>
><br>
><br>
> --<br>
> openssl-users mailing list<br>
> To unsubscribe: <a href="https://mta.openssl.org/mailman/listinfo/openssl-users" rel="noreferrer" target="_blank">https://mta.openssl.org/<wbr>mailman/listinfo/openssl-users</a><br>
<br>
<br>
<br>
--<br>
Regards,<br>
Ajay<br>
</blockquote></div></div>