[zeromq-dev] Vulnerability of devices to incoming messages

[Jon Dyte]

Matt Weinstein wrote:
> On Aug 11, 2010, at 3:12 PM, Jon Dyte wrote:
>
>   
>> whilst on the subject of devices and the good points made within  
>> this thread
>> I do have some reservations about these more 'esoteric' uses and the
>> existing devices.
>>
>> initially we had
>> 1) queue which conventionally takes XREP/XREQ pair
>> 2) forwarder which conventionally is SUB/PUB
>> 3) streamer which is UPSTREAM/DOWNSTREAM (or it's renames!)
>>
>> as people are pointing out it's quite possible to combine sockets of
>> other types in the devices
>> as well as connect other-than-intended peer sockets. some of these are
>> really insightful ideas
>> but i do wonder whether the 'core' devices shouldnt stick to intended
>> sockets.
>>
>>     
>
> In theory, you could do this:
>
> [[[ clients ]]] [ REQ ]* --- [ XREP ]  [ DEVICE ]  [ PAIR ] =/\/\/ 
> (network)\/\/\= [ PAIR ]  [ DEVICE ] [ XREQ ] --- [ REP ]*  
> [[[ servers ]]]
>
> and it should work and be "standard" relative to the specs.
>
>   
>> Most of the other uses seem to have involved people writing new code  
>> as
>> well which is fine,
>> because I don't think these devices should cater for all situations,  
>> but
>> equally not crash ....
>>
>>     
>
> Standard devices are fine, but cannot be overly restrictive, because  
> they only have limited information.
>
> Don't forget a lot of the solutions out on this list are laboratory  
> specimens, and there's a bit of experimentation and caveat emptor if  
> you overshoot the limits.
>   

Yes I realise, this, I think some the of uses posted are wonderful and 
clever.

I have been looking at yr zmq_reactor for  example, because I think it 
could make writing more
complex interactions simpler.
> The crash occurred because an input specification was not met.   There  
> are several ways to fix that within the current architecture.   
> Ensuring it "stays fixed" crosses the old invisible line between  
> "coding" to "systems engineering".
>
> So far, I've been delighted with what ØMQ can achieve "out of the box"  
> and would have had to reinvent the paradigms if they weren't already  
> present.
>
>   
I think what you get out of the box is excellent and fairly easy to get 
going with.

>> I was under the impression that the sockets exchanged a 1 byte message
>> on connection. Could
>> they also check they are compatible and terminate the connection if  
>> not?
>>
>> jon
>>
>> _______________________________________________
>> zeromq-dev mailing list
>> zeromq-dev at lists.zeromq.org
>> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>>     
>
> Best,
>
> Matt
>
>
> _______________________________________________
> zeromq-dev mailing list
> zeromq-dev at lists.zeromq.org
> http://lists.zeromq.org/mailman/listinfo/zeromq-dev
>
>