[zeromq-dev] Vulnerability of devices to incoming messages

[Brian Granger]

On Wed, Aug 11, 2010 at 12:12 PM, Jon Dyte <jon at totient.co.uk> 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!)
>
>
In my mind, a device is a particular send/recv pattern.  Those send/recv
patterns are independent of the socket types.  As long as you use socket
types that support the send/recv pattern, it should work.  Locking devices
to socket types will mean we have to implement lots of different devices
that do the same exactly send/recv pattern.  I don't think that makes sense.


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


> 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 ....
>
>
Devices should be hard to crash, not easy though.



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



-- 
Brian E. Granger, Ph.D.
Assistant Professor of Physics
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu
ellisonbg at gmail.com
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.zeromq.org/pipermail/zeromq-dev/attachments/20100811/f3ea1bb9/attachment.htm>