[zeromq-dev] Jyre Zyre

[techbird]

Hello Pieter.

Could you provide some direction.  After making the protocol changes - 
Jyre and Zyre clients time out.  I've work this through and discovered 
that...

Jyre uses a string for the sender identity UUID, and Zyre uses a binary 
representation. This prevents the UUID from being un-marshalled 
correctly.  And the peers timeout.

Which is preferred binary or string representation for the peer's UUID?


On 19/04/14 20:24, techbird wrote:
> Hiya Pieter.
>
> thank you - I've started taking a look, made a little progress updating the protocol.
>
> Problem is I've had to stop to make supper, fillet a large salmon, and now I have an hour back on the computer (with a glass of wine).
>
> Got the Jyre talking to Zyre now... sorted out the differences String vs lString etc.  Zyre is timing out now, so I'll read further and see what's what! :)
>
> Thank you, by the way I do code 'C', Python and Java ... but it's nolonger my day job so I am not as quick as some.
>
> On 19/04/14 19:25, Pieter Hintjens wrote:
>> techbird, if you make a start and come back with issues you hit, we'll help you.
>>
>> On Sat, Apr 19, 2014 at 4:10 PM, techbird<techbird at birdsoft.co.uk>  wrote:
>>> Hiya Pieter.
>>>
>>> Of course you're right. - better to work in the present.  The other option
>>> is to write my consumer using Pyre, but  my other components live in
>>> Camel/Karaf.  So maybe it makes sense for me to stay in the world of Java.
>>>
>>> I guess a lack of knowledge and time makes me apprehensive.  Pushing that
>>> aside - I'll start looking at the code.
>>>
>>> Thank you Pieter :)
>>>
>>>
>>> Like everyone else my problems are a lo
>>>
>>>
>>> On 19/04/14 13:18, Pieter Hintjens wrote:
>>>
>>> My advice would be to take the latest ZRE protocol spec (RFC 36) and
>>> upgrade Jyre to work with that. It'll teach you quite a lot about the
>>> details and it's easy to test against Zyre. Otherwise you check out an
>>> older version of Zyre from github, from the moment we forked off Jyre.
>>>
>>> The stacks are fun... I'm using Zyre in some projects and it does make
>>> life simple.
>>>
>>> -Pieter
>>>
>>> On Sat, Apr 19, 2014 at 1:08 PM, techbird<techbird at birdsoft.co.uk>  wrote:
>>>
>>> Thank you kindly for your support yesterday.
>>>
>>> "Jyre should talk to Zyre and implement the same functionality (it will need
>>> some updates since Zyre has evolved a little)"
>>>
>>> I gave it a go.  Zyre protocols have evolved away from the trunk Jyre - but
>>> independently both C and Java implementations work.  As the protocols,
>>> beacon ports etc are different Jyre clients do not communicate with trunk
>>> zyre and visa-vera.
>>>
>>> Is there a earlier version of Zyre I could use which is compatible with
>>> trunk Jyre?  I would like to write a 'producer' in C, and competing
>>> consumer(s) in Java.
>>>
>>> As an aside - I am only 2 days into 0MQ, and -  my jaw is dropping - this
>>> project is amazing.  Thank you so much for so much wisdom translated into an
>>> incredible set of integration stacks.
>>>
>>> Kind regards.
>>>
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>>>
>>>
>>> _______________________________________________
>>> zeromq-dev mailing list
>>> zeromq-dev at lists.zeromq.org
>>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>
>
> _______________________________________________
> 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/20140420/1dfe53d6/attachment.htm>