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" wrote:
> Thanks
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.
> From: openssl-users [mailto:openssl-users-boun...@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
On Sun, Oct 9, 2016 at 10:55 PM, Viktor Dukhovni
wrote:
>
>> On Oct 9, 2016, at 10:47 AM, Ajay Garg wrote:
>>
>>> However, it might sometimes return SSL_ERROR_WANT_READ, in which
>>> case, the SSL layer wants to read, even though the
> On Oct 9, 2016, at 10:47 AM, Ajay Garg wrote:
>
>> However, it might sometimes return SSL_ERROR_WANT_READ, in which
>> case, the SSL layer wants to read, even though the application
>> wants to write. Your job is to do the read on the SSL layer's
>> behalf, and then
Hi Viktor.
On Fri, Oct 7, 2016 at 11:17 PM, Viktor Dukhovni
wrote:
> On Fri, Oct 07, 2016 at 10:30:06PM +0530, Ajay Garg wrote:
>
>> Ok, so for sending app-payload-bytes, we do a bio_write() to "bio1",
>> and if "bio1" requires reading from bio2/peer, bio_write() will
Thanks Viktor.
On all our device-types, we are using blocking-sockets, but reads can
signal that no data is available (equivalent to SO_RCVTIMEO value set
as the socket-option on linux-like systems).
It seems you have provided me enough insight to get my hands dirty :)
Thanks and Regards,
Ajay
On Fri, Oct 07, 2016 at 10:30:06PM +0530, Ajay Garg wrote:
> Ok, so for sending app-payload-bytes, we do a bio_write() to "bio1",
> and if "bio1" requires reading from bio2/peer, bio_write() will return
> SSL_ERROR_WANT_READ (even for blocking sockets). We then read-in some
>
Thanks for the reply Viktor.
On Fri, Oct 7, 2016 at 8:27 PM, Jakob Bohm wrote:
> On 07/10/2016 16:35, Ajay Garg wrote:
>>
>> Hi Viktor.
>>
>> Thanks for your reply, and I am sorry for being idiotic, OpenSSL does
>> seem daunting, but I am learning :)
>>
>> Also, let's not
On 07/10/2016 16:35, Ajay Garg wrote:
Hi Viktor.
Thanks for your reply, and I am sorry for being idiotic, OpenSSL does
seem daunting, but I am learning :)
Also, let's not bother too much about the APIs/methods as such.
I will be grateful if you could confirm/reject my
Hi Viktor.
Thanks for your reply, and I am sorry for being idiotic, OpenSSL does
seem daunting, but I am learning :)
Also, let's not bother too much about the APIs/methods as such.
I will be grateful if you could confirm/reject my
architectural-understanding so far.
Let's say "bio1" is the
On Fri, Oct 07, 2016 at 12:28:46PM +0530, Ajay Garg wrote:
> I realise I am still stuck with the original issue.
Failure to read the documentation closely.
> Also, how do "bio1" and "bio2" communicate in case of non-ideal
> scenarios (timeouts, errors)?
They don't, you move all the data. All
Victor,
I realise I am still stuck with the original issue.
Taking "bio1" as the SSL-facing-bio, and "bio2" as the
network-facing-bio, how do we write-into/read-from "bio2"?
Are there callbacks available that will allow ::
* Writing to network via "bio2" (after "bio1" has
On Fri, Oct 7, 2016 at 9:19 AM, Viktor Dukhovni
wrote:
> On Fri, Oct 07, 2016 at 08:51:24AM +0530, Ajay Garg wrote:
>
>> However, I am a bit unsure about certain implementations.
>> In particular (let's talk only about the client-side), I wonder how do
>> the following
14 matches
Mail list logo