[zeromq-dev] how to implement the subscriber in the black box pattern

[Pieter Hintjens]

It'd have to be the connecting side, otherwise you open a trivial DoS
hole...


On Thu, Sep 19, 2013 at 2:26 PM, <Richard_Newton at waters.com> wrote:

> What side would get the error, presumably the connect side?  We would
> assume the bind side was always correct?
>
> Ric.
>
>
> [image: Inactive hide details for "Pieter Hintjens" ---19/09/2013 11:02:03
> AM---OK, I've checked and libzmq master _does_ check socket]"Pieter
> Hintjens" ---19/09/2013 11:02:03 AM---OK, I've checked and libzmq master
> _does_ check socket types, thanks to our cherished Martin Hurton.
>
> From: "Pieter Hintjens" <ph at imatix.com>
> To: "ZeroMQ development list" <zeromq-dev at lists.zeromq.org>,
> Date: 19/09/2013 11:02 AM
> Subject: Re: [zeromq-dev] how to implement the subscriber in the black
> box pattern
> Sent by: zeromq-dev-bounces at lists.zeromq.org
> ------------------------------
>
>
>
> OK, I've checked and libzmq master _does_ check socket types, thanks
> to our cherished Martin Hurton.
>
> Commit 2a4aef is the one. The code is in mechanism.cpp:check_socket_type.
>
> My comments about raising the error to the user still apply; we now
> get a failed connection but no signalling to the application.
>
> -Pieter
>
> On Thu, Sep 19, 2013 at 11:57 AM, Pieter Hintjens <ph at imatix.com> wrote:
> > This was certainly our intention. I'm not sure the code does that type
> > checking yet, but the protocol supports it.
> >
> > However, it's not as simple as it sounds, since connections are
> > background actions and invisible to applications. So connection
> > failures are too. We have the same issue with security, and the
> > current answer is to simply deny the connection, as if there was no
> > network connection. But this won't help users debug problems. I'm not
> > a fan of having to do extra work (context monitoring) to catch such
> > errors.
> >
> > Perhaps the better approach is to raise a fatal error on the socket so
> > all further operations on it fail, after a socket type error, or a
> > security failure. The error would happen asynchronously, but would at
> > least show on the radar without extra work.
> >
> > -Pieter
> >
> >
> >
> >
> >
> > On Thu, Sep 19, 2013 at 11:34 AM, Charles Remes <lists at chuckremes.com>
> wrote:
> >> Will the upcoming version 4 release enforce proper socket pairings so
> that doing something odd like connecting PUSH and SUB will raise an error?
> >>
> >> cr
> >>
> >> On Sep 19, 2013, at 2:46 AM, Pieter Hintjens <ph at imatix.com> wrote:
> >>
> >>> You can't connect a PUSH to a SUB; use a PUB socket to send the data.
> >>
> >> _______________________________________________
> >> 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
>
>
> ===========================================================
> The information in this email is confidential, and is intended solely for the addressee(s).
> Access to this email by anyone else is unauthorized and therefore prohibited.  If you are
> not the intended recipient you are notified that disclosing, copying, distributing or taking
> any action in reliance on the contents of this information is strictly prohibited and may be unlawful.
> ===========================================================
>
>
> _______________________________________________
> 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/20130919/595da695/attachment.htm>