For your own purposes however - you can define any behaviour you like
for sending and interpreting out-of-band data as long as you keep it
parallel to the SSL/TLS (the SSL/TLS stream data can't arrive out of
order). This would be independant of OpenSSL (and any other SSL/TLS
implementation) - and you would have to control the implementation at
both ends of the connection. If this is for your own networking needs,
that may be something you can do and and have a use for. But this won't
help you if you want to talk with applications whose implementation you
can't control. Nor will it help you if you want your applications to be
compliant with standards you can't influence.

Anyway, that's the long version of Jeffrey's more concise explanation!
:-)

Understood - I appreciate the explanation as it makes things a bit easier as it would be for my own server/client and would make things much easier on me protocol wise. I may just "emulate" oob data by opening a second pipe and using one for "oob" and the other for "data". Ideally I am trying to design a protocol to support a new networked filesystem (in which the network part is as secure as possible, hence ssl/tls). Thanks again! Your well thought out reply is appreciated.

Nate

______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]

Reply via email to