On Monday 15 December 2008 11:57:36 Dave Cridland wrote: > On Mon Dec 15 19:49:15 2008, Justin Karneges wrote: > > TLS transports a stream of bytes. Saying a particular TLS packet > > must contain > > just one stanza is like saying a particular TCP packet must contain > > just one > > stanza. > > Actually, TLS transmits a series of records...
And TCP transmits a series of packets... The common application interface offered by a TCP lib, however, is that of a stream of bytes. > > I don't think a TLS lib would ever cause real delay, but it might > > attempt to > > put two sets of recently-written bytes into the same packet (just > > like a TCP > > stack might do). This is perfectly acceptable, and should remain > > so. > > No, a TLS lib won't - you can run them in and out of buffers if you > want, and in practise this is the hard part - persuading TLS to > neatly talk to something that isn't a socket. Once that's done, you > can assume that a SSL_write (or equivalent) will read in the > cleartext, wrap it into an encrypted record, and write the result out. Sure. In fact, our TLS lib operates in memory and not directly on a socket. The interface is still a stream of bytes though. I guess the interface could have been record/packet based, but nobody ever has that kind of expectation on TLS. I think the only difference between TCP and TLS here is that TCP is normally controlled by the OS and so it makes it harder to break the abstraction. However, just because we might be in a better position to break the TLS abstraction doesn't mean we should. -Justin
