the client has a gui (for now, just a window with one button to initiate the handshake and then send the data).
the server has no gui.
the command is sent across as a binary representation of a c struct. it is important that the struct remain extremely lean. i have spent a great deal of time trimming it down to only its true essentials (26 bytes).
when i click the button on the client app, it connects, performs the handshake (SSLv3), and upon success, sends across the raw binary contents of the data structure (26 bytes). on the other end, i take the structure, interpret it, print it to the screen, then send it right back (still encrypted). when it is received on the client side, it is interpreted and printed out there as well.
this _IS_ working. i see no problems so far. but, someone has pointed out to me that it is possible that sometimes the contents of the receive buffer (at either end) may get stuck there while openssl is waiting for more data.
is this true?
if it is true, what can i do to remedy this, besides padding the data that i send across? (because, as i mentioned, it has to remain very tiny. 26 bytes is even a little big for this application)
can i somehow force a flush from the other end? would disconnecting from the sending end cause stuck buffer data on the receiving end to flush?
hopefully, none of this even matters. hopefully i'm just being paranoid and it will continue to work using only 26 bytes of data just as it is working right now. ;-)
thanks.
- philip
______________________________________________________________________ OpenSSL Project http://www.openssl.org Development Mailing List [EMAIL PROTECTED] Automated List Manager [EMAIL PROTECTED]
