Rodney Thayer wrote:
> AND it introduces more processing in between your payload and TLS.
About 30 bytes per message, yes. If you're doing encryption, the
overhead of TLS is likely going to be larger than the overhead of BEEP.
If you can't spare 30 bytes per message, then you probably are getting
messages fast enough to pile them all up into one BEEP frame, so you get
2 extra bytes per message instead.
> "At the time of this writing, only one such transport is defined, in [4],
> which specifies BEEP over TCP."
>
> Now in fact it specifies BEEP over TLS, I gather.
I suppose if you consider TLS a transport protocol, you could say that
BEEP specifies how to change its own transport protocol. I don't think
people use this sort of terminology. Invoking TLS is part of BEEP. TLS
isn't a transport protocol as such. The spec defined BEEP over TCP, not
BEEP over UDP or BEEP over SNA or .... TLS is just something that runs
over TCP also.
> The point is, BEEP adds a layer of overhead that people are debating the
> value of.
The debate was already dealt with ages ago, and modifications to the
profile were made to minimize the overhead. The amount of processing
overhead introduced is roughly the same order of magnitude as the
processing overhead of using TCP instead of UDP, I would guess.
Basically, adding two mod-2^32 numbers together and converting them to
strings of ASCII digits is the extent of it. What part of the overhead
do you think is unacceptable, specifically, and why do you think that?
--
Darren New
San Diego, CA, USA (PST)
"I'm allergic to antihistamines."
"Oh? What do you break out in?"
