I really want to go to bed, but I felt I should write about this now since I probably will not be awake for a while.
I don't like the idea of using RTP or SIP. My gut as a network guy tells me it is a strange pick of a protocol. Honestly I don't know enough about the protocols to argue it down technically, although I have the RTP RFC open on my workstation right now. I'm not sure if I want to invest time researching the protocols very far.
Instead, let me point out a few things.
First, RTP and SIP are typically associated with Voip apps. Apparently some programs used RTP for video as well, but the dominant use is Voip I am pretty sure. I think it is maybe a little goofy to classify our touch data as multimedia. That could be a small discussion on its own, though.
What are our goals for choosing a protocol? Is it ultimate correctness and scalability? Or are we trying to just build something that works? We wouldn't even need a protocol before if we didn't choose to split the blob and gesture programs (I still think that is a good design choice).
If we wanted ultimate correctness, I think we would probably use a Tuio variant (which is apparently out of the picture) or think long and hard about a good protocol design ourselves (which we do not have time for.)
Since I think we are going for a standard of just building something "good enough", then we can put far simpler things on the wire. So why aren't we just doing the stupidest, rawest, simplest stuff over our socket? Choosing SIP or RTP doesn't totally save us from protocol design: we still have to devise a system of messages we would like to pass in the RTP stream -- some kind of protocol for messages, you might say. We just would not have to worry about error detection -- instead we get to learn some huge non-standard library.
If we are aiming for good enough, then we should just use TCP. Over loopback, there should be little or none dropped packets. Most of the latency from TCP is going to be from it managing reliability on an imperfect line, but when we talk to ourselves the line WILL be perfect. The only latency then is an extra few dozen bytes of memory copies, which hopefully is not that big of a deal. If we really reall cared, we could benchmark it ourselves and choose.
In contrast to RTP, TCP is definately simple to program against and the same programming interface will exist on any system we could imagine. Ditto for UDP. For UDP though, we would probably want some degree of error detection. Simply computing some kind of checksum of the data sent/received before we do something important with it would be enough.
At the very least, if/when we discuss this subject, we should do it in light of updated assumptions: how forward-looking should the design be, how important is latency, do we care very much about this iteration having good performance BETWEEN different machines or not, etc.
10 years ago