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 <[email protected]> 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 <[email protected]> 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" <[email protected]> wrote: > >>> > >>> On Thu, Feb 5, 2015 at 8:41 PM, AJ Lewis <[email protected]> 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 > >>> [email protected] > >>> 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 > >> [email protected] > >> 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 > [email protected] > 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: [email protected] ---------------------------------------------------------------------- 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. _______________________________________________ zeromq-dev mailing list [email protected] http://lists.zeromq.org/mailman/listinfo/zeromq-dev
