search

bloom-lang / bud

Prototype Bud runtime (Bloom Under Development)
http://bloom-lang.net
Other
854 stars 60 forks source link

Support TCP channels + TCP semantics #100

Open neilconway opened 13 years ago

neilconway commented 13 years ago

We currently provide unreliable channels, implemented via UDP. This is perfectly reasonable, but most applications will want something a bit more sophisticated:

  1. Flow control / congestion avoidance
  2. Packet fragmentation and reassembly -- trying to send large tuples via UDP is unlikely to be successful
  3. Reliable delivery
  4. Ordered delivery -- at least in some cases (#7)

We could implement this stuff in Bloom on top of reliable channels, but another approach would be to provide support for sending messages via TCP. This raises some interesting questions:

billmarczak commented 13 years ago

lol, did we seriously replace TCP with UDP without leaving an option for TCP?

neilconway commented 13 years ago

Yup.

billmarczak commented 13 years ago

that sucks, can i check it back in as an option?

neilconway commented 13 years ago

Maybe cleanest would be to add support for specifying TCP transport in the channel syntax.

Why do you need TCP, btw?

billmarczak commented 13 years ago

for flow control and reliable delivery mainly; my RTrace thing sends a lot of trace info at the end of a computation (timings of all sent messages and elapsed timestamps) back to a master and i'm worried that the deluge of data will overflow buffers and cause data to get lost. i haven't actually tested this yet because my RTrace thing isn't yet working.

that brings me to my second point, which is that in debugging my code, i'd like to be able to rule out the possibility of "UDP randomly dropped this message" when considering why my code isn't working like i expect.