On Sun, Feb 8, 2015 at 1:14 AM, Pieter Hintjens <[email protected]> wrote:
> On Sun, Feb 8, 2015 at 12:53 AM, MinRK <[email protected]> wrote: > > > I guess the problems I identified that it solves weren't really problems, > > then. > > Where in the email below are you identifying the problems that the > experimental split of multipart messages into labels + parts was > trying to solve? > Sorry, on re-reading, I guess there was more information in my head than in my email. I shouldn't have sent that. Status quo problems, prompting the CLIENT/SERVER proposal: Problem: multi-part messages cannot be sent in a single atomic API call Problem: all ROUTER messages are multi-part because the first frame is needed for routing Problem: using multi-part message frames for both content and routing is confusing Proposed CLIENT/SERVER solves the above by: - msg.routing_id separates routing and content - eliminate multi-part Problems with the proposal: Problem: single routing_id doesn't support multi-hop use cases Problem: eliminating multi-part eliminates zero-copy framing These are the identified problems the idea aimed to address. Of course, that still doesn't mean it's a good idea, so I'm happy to let it die. -MinRK > > -Pieter > > > If I recall correctly, libzmq-3.0 (or was it the old 4.0 experimental > > branch?) preserved multi-hop while separating routing from content by > > making the routing id a sequence rather than a single value. That way, > > it seems that the same push/pop behavior that happens on a ROUTER-DEALER > > device today could still work on CLIENT-SERVER. The push/pop would be > > happening on the routing stack instead of message content. > > > > If a message were something like: > > > > { > > frame_t frames[]; > > int nframes; > > routing_id_t route[]; > > int nroutes; > > } > > > > it would seem that you could have multi-part content (selfishly, in the > > way that affects me - messages composed of non-contiguous memory), > > multi-hop routing, and send it all with a single `zmq_send_newfangled` > > call, allowing future attempts at making `zmq_send_newfangled` a > > threadsafe call. > > > > There may be reasons this would be super gross and horrible, but it's an > > idea, anyway. > _______________________________________________ > zeromq-dev mailing list > [email protected] > http://lists.zeromq.org/mailman/listinfo/zeromq-dev >
_______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
