[Nice] New API and refactor

[Rémi Denis-Courmont]

On Wednesday 30 July 2008 20:59:18 ext Youness Alaoui, you wrote:
> And yes, we need to make the usages completely separated from the stun
> agent and the transport, simply because of TURN and google relay.. the
> google relay uses Send requests and Data indication messages to
> send/receive data, with the stun message being inside the data. (so you
> get a stun message wrapped inside a stun message).

You should anyway not use a transaction to send/receive STUN Indication. Not 
even to receive Requests and send Replies and/or Errors. So the point about 
Send and Data indication is moot.

The transaction code implements, well, the STUN Requests transaction. As I 
said, reimplementing the retransmission timers, sanity checks on the receive 
answers, and stuff such as redirections in every single usage would suck 
(IMHO). Precisely, TURN (at least the standard version) has several types of 
transaction, all using the same logic as the Binding request in STUN. I am 
very much not convinced that cut&paste is the right way to implement this.

> > It only creates socket if the application does not bother doing so. In
> > the ICE case, that code is (as far as I remember) not used.
>
> Well, that's the point, it doesn't "need" to create or use the socket..
> as I said before, google relay for example (TURN as well, I'm sure)
> isn't just about a socket, it's about wrapping the whole message into
> Send requests, so it just should not take care of that.

It does probably not need to create sockets, as the application can/should do 
it. But it does need to access the socket, if only to write to it. You might 
want to "wrap" that socket access into a higher layer interface, but that 
does not really change the fact that it will need to access the socket 
anyway.

And please forget about TCP and TLS. That's a completely different model. With 
UDP, we use sendto/recvfrom, since it's not connected. We also can assume 
non-blocking write, and non-buffered read (one read = one entire and only one 
packet). I won't make the insult of explaining why TCP (or TLS over TCP) are 
going to be totally different.

-- 
Rémi Denis-Courmont
Maemo Software, Nokia Devices R&D