[SWMP] Re: introducing RPC to an asynchronous protocol

[[e-mail]]

Jay:

I understand your concern about having request-response style messaging. I 
am worried that it cannot be completely avoided.  Once we assume that 
there are multiple nodes to subscribe to, we face the possibility that it 
will be necessary to query the nodes to determine which one to subscribe 
to.   Moreover, if you saw my discussion of a swmp url, we might find it 
desirable to query a node for some information (ie, the URL of its static 
representation) prior to actually subscribing.

I do not feel that a query response capability in the protocol should be 
equated with an RPC mode of interaction.  The problem in RPC is not that 
the protocol messages are synchronous; they're not.  It is that the API 
for accessing the protocol is synchronous.  A listener or callback 
approach can deal with this.

I agree that a query facility might be problematic for a lossy transport 
so I would not recommend that it be used there.  Frankly, the SUBSCRIBE 
message is even more problematic for UDP if the sequence of state updates 
that ensue are critical.  My guess is that the decision of when to use TCP 
and when to use UDP for swmp will be a matter of some delicacy within an 
application.  Personally, I would probably use TCP for most things and 
only use UDP for streams of updates where the loss of one update is no big 
deal (eg, position updates.)  Indeed, one of the things I would like to do 
is subscribe on a TCP channel for updates that will occur on a UDP 
channel.  I don't think we have anticipated that yet.

jfp



"Jay C. Weber" <[e-mail]> 
08/24/2007 12:03 PM

To
[e-mail]
cc
[e-mail]
Subject
introducing RPC to an asynchronous protocol






[e-mail] wrote:
D)  I believe that swmp will need the full complement of CRUD (create, 
read, update, delete) operations.  I think the absence of read methods 
derived from the implicit subscription to all state.  Now, that one can 
subscribe to some, but not all of the state, I believe it will become 
desirable to request the values of unsubscribed state.  This prompted me 
to add a GETNODE and a GETFIELD request, which required GETNODEREPLY and 
GETFIELDREPLY messages to return the response. 
Interesting, but the danger here is "return the response".  There's a big 
advantage to resisting the introduction of RPC-style elements in a context 
of minimizing latency -- obviously RPC involves a round-trip of messaging. 
 Keeping SWMP asynchronous will keep it mapping simply and efficiently 
onto datagram transports.

I like the PUB-SUB suggestions you've made, especially because PUB-SUB can 
be designed to work well in an asynchronous protocol.

jay
-- 
Jay C. Weber, Ph.D. 
CTO, Media Machines Inc. 
650-279-2311 

_______________________________________________
SWMP mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/swmp