Yes, SSL_read() may only return one record. But the underlying recv()
could have read 64K bytes (but I guess from what you have written that
it would never read more than 16K). Further SSL_read()s would access the
data previously recv()d.
The fewer times recv() is called (for the same amount of data), the
faster the application.
> -----Original Message-----
> From: [EMAIL PROTECTED]
> [SMTP:[EMAIL PROTECTED]]
> Sent: Monday, May 31, 1999 4:25 PM
> To: [EMAIL PROTECTED]
> Subject: Re: SSL_read problem?
>
> > While it is true that the maximum TLS record size is 16k, this doea
> not
> > relate directly to the TCP handling.
>
> > For example, the server hello, certificate request, etc are
> individual
> > records but they are all bundled into the one TCP record because it
> is
> > (apparently) more efficient to perform fewer reads.
>
> > Does the TLS spec prohibit writing four 16k TLS records as one 64k
> TCP
> > record?
>
> No (well, the requirement to reply to close_notify "immediately",
> "discarding any pending writes" could be read as prohibiting it unless
> the application knows how large the current TCP sending window is, but
> it's nonsense anyway -- we always have some amount of concurrency, and
> no OS provides an atomic "check for arrival of close_notify and send
> out TCP data only if appropriate" system call). I'd think that one
> could in s[23]_pkt.c use a buffering BIO module for large writes just
> as it is used during handshake.
>
> But note that this would not change the behaviour of SSL_read; you'd
> still only obtain at most a single record per SSL_read.
> ______________________________________________________________________
> 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]
