[email protected] said: > > This is starting to look the the 'udp' transport we don't have (yet) :-) > > This is starting to look messy: rename udp->epgm, then introduce brand > new, incompatibel udp...
Not really. As we decided, udp is renamed to epgm but a deprecated udp 'alias' sticks around for a couple more releases. The ABI is still "Beta" so it's not set in stone. If an unreliable udp transport is available after that then it can be reintroduced as 'udp' if it seems like a good idea :-) > > Why would you need to know when a packet was lost, it is after all just > > unreliable multicast... > > > > What I see as more of a problem is that UDP datagrams are limited to 65,507 > > bytes in length, so any 0MQ UDP transport (multicast or unicast) would have > > to split and recombine messages. > > Bingo. See what packet numbers are good for? Yes, but once you introduce sequence numbers you're going to need a handshake to initialise those, which means a "virtual connection" of some sort, and if you want to do that using multicast I guess you'll end up with something like PGM anyway :-) Now, the question is, would it make sense to make just a *plain* UDP transport? I.e. you try to send a message larger than the maximum datagram size, you get an error back from 0MQ. Nothing wrong with that. You can then trivially have a connectionless unicast or multicast UDP transport. I guess the answer depends on what applications Chris has in mind. -mato _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
