Subject: Re: [SWMP] Media Machines' initial design and code

From: "Jay C. Weber" <[email-masked]>
Date: Thu, 31 May 2007 21:35:46 -0700

chris wrote:
>  That is, at leasts two: high bandwidth, secure protocol over tcp/ip, 
> short payload, low latency protocol over udp.
As described in that paper I linked, the SWAMP design already can use 
TCPand/or UDP depending on the delivery requirements of a particular 
kind of message.  That is, some messages (like object instantiation) 
need guaranteed delivery, and are usually infrequent, suggesting TCP.  
Other messages (like position-changes) are streamed and need low 
latency, suggesting udp.  It's also valuable to use tcp as a fallback 
when udp ports are blocked by firewalls.

The initial implementation only roughs-in the UDP parts, though, that's 
not working yet.  But you'll see that some parts of the design (e.g., 
enveloping) are there to support UDP datagrams.
> And we may even be looking at different protocols for server-server, 
> client-server and client-client for ultimate scalable system.
Perhaps, but it certainly would be preferable if these architectural 
connections could use a unified protocol.
> On the practical front, I have managed to compile hydras for both 
> windows and linux and the local test works on my winxp client. Still 
> trying to get it to work accessing the remote linux server, but that 
> should be working soon - it might just be a matter of the port being 
> blocked.
Excellent.

jay

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

---

From: "Jay C. Weber" <[email-masked]>
Date: Fri, 01 Jun 2007 05:54:09 -0700

Here's the gist of how we can support tcp (stream) and udp (datagram) 
transports in one application protocol.

A base-message consists of an op-code and parameters.  A conversation 
over tcp is a stream of base messages, where the first messages 
establish the context for the rest of the messages, including 
authentication information.  I.e., the first message each side sends is 
"hello" with a "ticket" parameter containing authentication data.

Since udp datagrams don't have a connection context, each datagram needs 
to securely establish its own context.  So a datagram-message wraps a 
base-message with ticket data (as well as a sequence-number, since like 
many real-time protocols, message order is relevant).  In SWAMP, two 
agents first establish a tcp connection and thereby establish ids for 
each other, to be used in the datagram ticket data.  That is, there is a 
baseline tcp connection between the two, which may then choose to use 
udp datagrams for low-latency message exchange.

Who decides to use one transport or another?  This could just be under 
application logic control, but I think there is a very useful heuristic 
available.  SWAMP contains two messages for communicating entity-state 
information: "set" and "setf".  A set message contains string references 
to the entity and property names, and as these names tend to not be very 
compact, is suitable for messages that are sent relatively 
infrequently.  However it also has a fieldId parameter that assigns a 
compact numeric id to that entity-name and property-name pair.  Agents 
cache the fieldId information in a working set of state variables, to 
support subsequent setf messages, which are relatively compact and more 
suitable for frequent transmission.  Thus the heuristic is to sent 
set-messages over the tcp stream, and setf-messages over udp.

This means that the initial value of an entity-state variable is set 
using tcp (reliable delivery) and then frequent updates to the variable 
are sent using udp (low-latency).  This seems to me to be the ideal 
combination of the transports.

jay