protocol.dispatch returns nothing

[Michael Salmon]

Just wondering why protocol.dispatch() returns nothing, while serverfactory.dispatch() returns a deferred? Would be nice to use a deferred (and the callback, and setTimeout) mechanism to help ensure push messages get to a client successfully before doing something else (i.e. apple push).

Thanks,

Michael

[Tobias Oberstein]

Am 14.05.2013 04:10, schrieb Michael Salmon:
> Just wondering why protocol.dispatch() returns nothing, while
> serverfactory.dispatch() returns a deferred? Would be nice to use a

Yep, agree. The good thing: this is already fixed on master branch.

> deferred (and the callback, and setTimeout) mechanism to help ensure
> push messages get to a client successfully before doing something else
> (i.e. apple push).

The deferred will fire when the event has been dispatched to all
receivers. Note that "dispatched" in this context means: the serialized
event bytes have been written to the respective sockets. This does not
mean the bytes have already traveled the wire, nor that the peer has
received those bytes in socket buffers, nor that the peer has processed
the event (neither on WAMP level nor app level).

IOW: this is no mechanism for app level reliable transmission/processing ..

>
> Thanks,
> Michael
>
> --
> You received this message because you are subscribed to the Google
> Groups "Autobahn" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to autobahnws+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

[Michael Salmon]

Why can't the software managing the socket  (twisted?) signal a tcp error to autobahn if the payload ack's haven't been received for the wamp payload? It's not guaranteed of course if a proxy does something bad, or a network connection goes down, but it would help. In general it seems like reliability though needs to be handled by the app developer to acknowledge receipt of callIds, something like app level ack tables of callIds. Is this something autobahn would consider a good feature to have in future?

[Tobias Oberstein]

Am 23.05.2013 09:59, schrieb Michael Salmon:
> Why can't the software managing the socket (twisted?) signal a tcp
> error to autobahn if the payload ack's haven't been received for the

On the TCP level, ACKs are managed by the TCP/IP stack within the
kernel. These mechanisms are not exposed to user level code.

> wamp payload? It's not guaranteed of course if a proxy does something
> bad, or a network connection goes down, but it would help. In general it
> seems like reliability though needs to be handled by the app developer
> to acknowledge receipt of callIds, something like app level ack tables
> of callIds. Is this something autobahn would consider a good feature to
> have in future?

CallIDs are only used with WAMP RPC, and with RPC you already get app
level feedback: either call success or error. WAMPv2 will add call timeouts.

Also note that you can use RPCs in both directions: a "server" calling a
procedure exposed on a "client". This is currently only implemented in
AutobahnPython, but we'll add it to the other Autobahn libs as well.

Rgd. QoS with PubSub: this is still discussed for WAMPv2 .. you can have
a look at the issues on the GitHub repo https://github.com/tavendo/wamp/
if you are interested and/or wanna join the discussion ..

>
> On Thursday, May 16, 2013 1:46:00 AM UTC-7, Tobias Oberstein wrote:
>
> Am 14.05.2013 04:10, schrieb Michael Salmon:
> > Just wondering why protocol.dispatch() returns nothing, while
> > serverfactory.dispatch() returns a deferred? Would be nice to use a
>
> Yep, agree. The good thing: this is already fixed on master branch.
>
> > deferred (and the callback, and setTimeout) mechanism to help ensure
> > push messages get to a client successfully before doing something
> else
> > (i.e. apple push).
>
> The deferred will fire when the event has been dispatched to all
> receivers. Note that "dispatched" in this context means: the serialized
> event bytes have been written to the respective sockets. This does not
> mean the bytes have already traveled the wire, nor that the peer has
> received those bytes in socket buffers, nor that the peer has processed
> the event (neither on WAMP level nor app level).
>
> IOW: this is no mechanism for app level reliable
> transmission/processing ..
>
> >
> > Thanks,
> > Michael
> >
> > --
> > You received this message because you are subscribed to the Google
> > Groups "Autobahn" group.
> > To unsubscribe from this group and stop receiving emails from it,
> send

> > an email to autobahnws+...@googlegroups.com <javascript:>.

> > For more options, visit https://groups.google.com/groups/opt_out

> <https://groups.google.com/groups/opt_out>.