[zeromq-dev] Notes from a hackathon

[MinRK]

On Sun, Feb 8, 2015 at 1:14 AM, Pieter Hintjens <ph at imatix.com> wrote:

> On Sun, Feb 8, 2015 at 12:53 AM, MinRK <benjaminrk at gmail.com> 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
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20150208/333f0634/attachment.htm>