How to map recv(fd, buffer, SEGMENT_LEN, MSG_PEEK) to SSL_read

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

How to map recv(fd, buffer, SEGMENT_LEN, MSG_PEEK) to SSL_read

tony vong
Dr Stephen,
I want to map recv(fd, buffer, SEGMENT_LEN, MSG_PEEK)
to some kind of SSL_read.

MSG_PEEK
              This flag causes the receive operation
to return data  from  the
              beginning  of  the receive queue without
removing that data from
              the queue.  Thus, a subsequent receive
call will return the same
              data.

Is it possible ?

Tony


               
__________________________________
Discover Yahoo!
Find restaurants, movies, travel and more fun for the weekend. Check it out!
http://discover.yahoo.com/weekend.html 

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: How to map recv(fd, buffer, SEGMENT_LEN, MSG_PEEK) to SSL_read

JoelKatz

> Dr Stephen,
> I want to map recv(fd, buffer, SEGMENT_LEN, MSG_PEEK)
> to some kind of SSL_read.
>
> MSG_PEEK
>               This flag causes the receive operation
> to return data  from  the
>               beginning  of  the receive queue without
> removing that data from
>               the queue.  Thus, a subsequent receive
> call will return the same
>               data.
>
> Is it possible ?

        Because this is so ugly, I would advise you to just receive it normally and
keep it in your own buffer to receive again. That's assuming there's no way
you can rearchitect the code not to use this.

        DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: How to map recv(fd, buffer, SEGMENT_LEN, MSG_PEEK) to SSL_read

Steven Reddie
Adding to David's response...

MSG_PEEK is problematic on some systems.  On Windows for example (maybe only
the 9x series, but a problem none-the-less) using MSG_PEEK will effectively
freeze the contents of the buffered data that can be seen with MSG_PEEK,
meaning that any further peeks will not be able to see any subsequently
received data.  This means that if you need to peek at 4 bytes and only one
has arrived when you perform the first peek you will never see the following
three bytes and will therefore hang or need to abort.

The BIO support in OpenSSL can help you.  By using a BIO to wrapper the
socket and buffer data that you want to peek/push-back-on you can get a
similar result.  There has been plently of BIO discussion on this list
recently and there are samples included with OpenSSL.

Regards,

Steven

-----Original Message-----
From: [hidden email]
[mailto:[hidden email]] On Behalf Of David Schwartz
Sent: Wednesday, 25 May 2005 9:47 AM
To: [hidden email]
Subject: RE: How to map recv(fd, buffer, SEGMENT_LEN, MSG_PEEK) to SSL_read


> Dr Stephen,
> I want to map recv(fd, buffer, SEGMENT_LEN, MSG_PEEK) to some kind of
> SSL_read.
>
> MSG_PEEK
>               This flag causes the receive operation to return data  
> from  the
>               beginning  of  the receive queue without removing that
> data from
>               the queue.  Thus, a subsequent receive call will return
> the same
>               data.
>
> Is it possible ?

        Because this is so ugly, I would advise you to just receive it
normally and keep it in your own buffer to receive again. That's assuming
there's no way you can rearchitect the code not to use this.

        DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]

______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: How to map recv(fd, buffer, SEGMENT_LEN, MSG_PEEK) to SSL_read

JoelKatz

> Adding to David's response...
>
> MSG_PEEK is problematic on some systems.  On Windows for example
> (maybe only
> the 9x series, but a problem none-the-less) using MSG_PEEK will
> effectively
> freeze the contents of the buffered data that can be seen with MSG_PEEK,
> meaning that any further peeks will not be able to see any subsequently
> received data.  This means that if you need to peek at 4 bytes
> and only one
> has arrived when you perform the first peek you will never see
> the following
> three bytes and will therefore hang or need to abort.

        Which could happen even without MSG_PEEK. TCP does not guarantee that it
can ever receive any particular number of bytes at one time. This is another
reason you will see such a violent knee-jerk reaction when you mention
MSG_PEEK -- it is usually used to try to force TCP to do something it cannot
do.

> The BIO support in OpenSSL can help you.  By using a BIO to wrapper the
> socket and buffer data that you want to peek/push-back-on you can get a
> similar result.  There has been plently of BIO discussion on this list
> recently and there are samples included with OpenSSL.

        Right. This way you still receive the data from the TCP or SSL engine
immediately, allowing it to do its job.

        DS


______________________________________________________________________
OpenSSL Project                                 http://www.openssl.org
User Support Mailing List                    [hidden email]
Automated List Manager                           [hidden email]