Hi,
Can you use the OPENSSL S_SERVER or S_CLIENT commands, depending on which part of your
program you want to use or see, and using -debug -msg -state parameters with these
client or server programs, see the data you are looking for in the protocol exchange?
The flush... Depends on processing ... BIO, etc.
Paul
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of P. George
Sent: Tuesday, October 26, 2004 5:04 PM
To: [EMAIL PROTECTED]
Subject: Re: stale buffer contents question
> i have a client app which connects over ssl to a server app (using my
> own custom protocol) and sends it commands to execute. for now, just
> to ensure that the commands are making it there in-tact and that
> responses will make it back to the client in-tact, i'm just echoing
> the commands back to the client, which then prints them to the screen.
>
> 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.
i just realized that it's a little worse than i had already
explained.... it's actually sending more than 26 bytes right now, isn't
it?
if i send the string "hello" across an openssl connection, it looks
like i'm sending 5 bytes on the client side and it looks like i'm
receiving 5 bytes on the server end, but somewhere in the openssl
layers between those two points (and most importantly when it's on the
wire), it's encrypted representation is something like 512 or 1k, isn't
it?
someone __please__ help me out here. this list seems so quiet
sometimes.
- philip
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
______________________________________________________________________
OpenSSL Project http://www.openssl.org
Development Mailing List [EMAIL PROTECTED]
Automated List Manager [EMAIL PROTECTED]
