[FoRK] Whither BEEP? Re: HTTP 0.2, 9p, and op

Sean Conner sean at conman.org
Thu Dec 24 17:02:01 PST 2009

It was thus said that the Great Stephen Williams once stated:
> Similar, but without assumptions on transport and with IETF application 
> protocol like framing (ASCII), yet very lightweight and able to be 
> optimized (pad numbers, etc.).

  Ah, silly me ... I thought that IP was the networking protocol that didn't
make assumptions on transport, but then again, I never did like the OSI 7
layer burrito.

> If SCTP were easily used both as the transport and over an arbitrary 
> transport and if it included TLS, then it would give you most or all of 
> what BEEP provides.

  I seem to be missing something.  SCTP rides on top of IP; what else would
you need SCTP to ride on top of, if IP isn't available?  (And yes, there are
RFCs covering IP over SCSI, ATM and avaian carriers, so I'm having
difficulty seeing where you would have SCTP and *not* IP)

> Another part of some problems is end-to-end flow control.  It would be 
> convenient if you could map transactions, messages, and chunks through 
> both each transport and over the whole message path using the same 
> mechanism, with or without various kinds of nesting.

  I'm haing trouble parsing that paragraph.  What do you mean by it all?

> SCTP as native & library, with UDT/Rate based flow, TLS, full TCP/select 
> semantics, and able to run over raw packets, TCP, UDP, UDT, HTTP, and 
> libOpenSkype, with a coherent solution for link vs. end-to-end flow 
> control would be the ultimate solution.  Where libOpenSkype == automatic 
> secure communication linkage between any 2 or more endpoints based on a 
> unique ID, secure authentication mechanism, and over any required 
> combination of communication link types to get the most efficient 
> communication path: local packets, TCP, UDP, UDT, routed directly in 
> whichever direction is required or routed through a "nearby" system with 
> some policy.  All intermediated by either a DNS-like neutral 
> coordination server, or ISP-nearby, or private configured coordination 
> server.  Perhaps also with distributed self-healing hash/cache like HTTP 
> cache / memcached + BitTorrent, pub/sub propagation, etc.

  Um ... yeah.  The only thing I have to say is ... I hope it doesn't break

> >  I took one look at the RFC for BEEP (RFC-3080) and saw:
> >
> >	At BEEP's core is a framing mechanism that permits simultaneous and
> >	independent exchanges of messages between peers.  Messages are
> >	arbitrary MIME [1] content, but are usually textual (structured using
> >	XML [2]).
> >
> >  Okay, so now my application needs to link against a MIME parser and an XML
> >parser (SAX, lighter weight but difficult to use, or DOM, easy to use but my
> >God the memory requirements [3]).  So now my app becomes a bit more
> >complicated.  Thanks, I'll stick to UDP [5].
> Those are naive assumptions.  First, for a typical application, you 
> would only implement the Mime types you are interested in, which 
> basically means you write a fixed string and read a fixed string, puking 
> on anything else.  A set of applications could even define private mime 
> types as very short strings.  The point is that the messages are typed 
> and allow Mime-compatible strings.  No library, no parsing. 

  No library I'll grant you, but there's still parsing, even if it is
minimal in nature.

> Second, 
> BEEP messages are opaque and can be anything you want, including Google 
> Protocol Buffers, XML, SMTP, images, etc.  The RFC is just saying that 
> XML messages work well with the text-based framing so you can debug 
> easily, in keeping with SMTP, Imap, HTTP, etc.

  As I keep reading the BEEP specification, I keep asking myself "Self,
what's the point?"  BEEP over TCP includes a window size, which is
duplicating what TCP already provides (but I can see why it's done, which is
to get around the whole "TCP dropped packets and blocking" issue, which gets
into the whole "leaky abstraction" thang and seems to introduce yet another
layer that can break on a whim).

  Looking even further, I see SOAP over BEEP and XML-RPC over BEEP and well
... it just seems overly engineered and complicated (just bcecause it can)
just to schlep bits from point A to point B and back.

  It also seems that a bunch of these layers exist solely to bypass
firewalls run by facist network admins that only allow ports 80 (which is
invisibly proxied anyway: http://boston.conman.org/2009/11/17.1) and 443
(and really, what's the port of allowing *any* open port if you can tunnel
anything through it anyway? http://boston.conman.org/2009/11/18.1), which
means that firewalls have to get more instrusive, complicated, and make
network troubleshooting all that more difficult (true story:  setting up a
route for a client in their cabinet at a large data center.  One hour later
and we still can't get to it from outside because a) the IP is private, and
b) the consultants we're working with for the client can't figure out how to
forward the network traffice from the public side to the router).

> Have you used SCTP?  Has anyone?

  Well, _Unix Network Programming, 3rd Edition_ shows that SCTP is used for
ISDN over IP, M2UA, M3UA (SS7 telephony signaling), H.248, H.323 (IP
telephony) and SIP.  So it is in use.

  -spc (Having a hard time wrapping my brain around all these layers)

More information about the FoRK mailing list