protocol.dispatch returns nothing

#1

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

0 Likes

#2

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

···

Am 14.05.2013 04:10, schrieb Michael Salmon:

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.

0 Likes

#3

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?

···

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.

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

0 Likes

#4

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

···

Am 23.05.2013 09:59, schrieb Michael Salmon:

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 autobah...@googlegroups.com <javascript:>.
     > For more options, visit https://groups.google.com/groups/opt_out
    <https://groups.google.com/groups/opt_out>.
     >

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

0 Likes