[zeromq-dev] Vulnerability of devices to incoming messages

[Matt Weinstein]

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.

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 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