[zeromq-dev] Notes from a hackathon

AJ Lewis AJ.Lewis at quantum.com
Fri Feb 6 21:41:58 CET 2015


On Fri, Feb 06, 2015 at 10:19:28AM +0100, Pieter Hintjens wrote:
> Actually one could just hold a stack of 16-bit routing IDs at the
> start of a message and push/pop these while forwarding.

A stack of (some length) routing IDs at the start of message would work
well for this I think and would address the multihop problem.

This doesn't address the use of having messages that don't need to be
decoded at each hop - I'm using multipart for this now because the first
tier of routing handles one message on the stack and ignores
everything else - it decides what to do with the rest of the message
stack based on that and sends it on.

This could be handled by sticking a blob in the first tier's message,
but it means that needs to be deserialized to read it every time, which
has potential performance impacts if the blob can be large (of course,
the blob still needs to be pushed around even with multipart, but at
least it doesn't have to be actively worked on).

> Let's slowly explore the client-server pattern, and perhaps over time
> this will become a usable replacement for existing socket patterns, or
> perhaps not. No stress.

Sure.
 
> Thanks to everyone for the feedback, this has been useful for me at
> least, and I hope to others.

Sounds good. 

AJ

> On Fri, Feb 6, 2015 at 9:53 AM, Pieter Hintjens <ph at imatix.com> wrote:
> > We should not touch this, if it's working and stable and people
> > actually use it. The nice thing about multiframing is you can push and
> > pop addresses without decoding the rest of the message. Honestly I
> > don't see a cleaner way to do multihop, except perhaps to reduce
> > message size (integer routing IDs instead of the 5-byte or longer IDs
> > used today).
> >
> > -Pieter
> >
> >
> >
> > On Fri, Feb 6, 2015 at 9:43 AM, Doron Somech <somdoron at gmail.com> wrote:
> >> Regarding multihope on ZProto we can have a stack of routing id (that will
> >> be serialized to the wire) and a method called reply and a method call
> >> forward. What do you think?
> >>
> >> On Feb 6, 2015 10:09 AM, "Pieter Hintjens" <ph at imatix.com> wrote:
> >>>
> >>> On Thu, Feb 5, 2015 at 8:41 PM, AJ Lewis <AJ.Lewis at quantum.com> wrote:
> >>>
> >>> > Is the plan really to drop multi-hop routing?
> >>>
> >>> I did want, and am glad to get, stories from people using multihop
> >>> routing.
> >>>
> >>> I think the situation here is that we're using the multihop
> >>> request-reply pattern, it depends on multipart, and that's fine. It's
> >>> a standard, it's implemented, and it's stable.
> >>>
> >>> So we can focus on new patterns (like client/server) quite separately,
> >>> and if we make threadsafe sockets, perhaps use them only in these new
> >>> cases.
> >>>
> >>> -Pieter
> >>> _______________________________________________
> >>> zeromq-dev mailing list
> >>> zeromq-dev at lists.zeromq.org
> >>> https://urldefense.proofpoint.com/v1/url?u=http://lists.zeromq.org/mailman/listinfo/zeromq-dev&k=8F5TVnBDKF32UabxXsxZiA%3D%3D%0A&r=R2zWNFHLVImAo2qABlJKsHZpXtrP7rtLmoGaa3CV1do%3D%0A&m=1VxxpdoYw9sa54If4BFOz1KTfg3AedlQ5kwDLjqupFk%3D%0A&s=963e3a75b9d55a2f32b970a98f3123ca29aa90dc4045b360c191db6ea2041658
> >>
> >>
> >> _______________________________________________
> >> zeromq-dev mailing list
> >> zeromq-dev at lists.zeromq.org
> >> https://urldefense.proofpoint.com/v1/url?u=http://lists.zeromq.org/mailman/listinfo/zeromq-dev&k=8F5TVnBDKF32UabxXsxZiA%3D%3D%0A&r=R2zWNFHLVImAo2qABlJKsHZpXtrP7rtLmoGaa3CV1do%3D%0A&m=1VxxpdoYw9sa54If4BFOz1KTfg3AedlQ5kwDLjqupFk%3D%0A&s=963e3a75b9d55a2f32b970a98f3123ca29aa90dc4045b360c191db6ea2041658
> >>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> https://urldefense.proofpoint.com/v1/url?u=http://lists.zeromq.org/mailman/listinfo/zeromq-dev&k=8F5TVnBDKF32UabxXsxZiA%3D%3D%0A&r=R2zWNFHLVImAo2qABlJKsHZpXtrP7rtLmoGaa3CV1do%3D%0A&m=1VxxpdoYw9sa54If4BFOz1KTfg3AedlQ5kwDLjqupFk%3D%0A&s=963e3a75b9d55a2f32b970a98f3123ca29aa90dc4045b360c191db6ea2041658

-- 
AJ Lewis
Software Engineer
Quantum Corporation

Work:    651 688-4346
email:   aj.lewis at quantum.com

----------------------------------------------------------------------
The information contained in this transmission may be confidential. Any disclosure, copying, or further distribution of confidential information is not permitted unless such privilege is explicitly granted in writing by Quantum. Quantum reserves the right to have electronic communications, including email and attachments, sent across its networks filtered through anti virus and spam software programs and retain such messages in order to comply with applicable data security and retention requirements. Quantum is not responsible for the proper and complete transmission of the substance of this communication or for any delay in its receipt.



More information about the zeromq-dev mailing list