[riot-devel] Network API task force

Oleg Hahm oliver.hahm at inria.fr
Fri May 8 14:34:33 CEST 2015


Hi Kaspar!

> Actually, how a network stack internally communicates should be kept to
> that stack. I was talking exactly for the upper layers, e.g., applications.
> 
> How do I bind to a UDP or TCP port? How do I write to a TCP connection?

Well, no, than you're talking exactly about the second type of API. One (an
application or an application layer protocol) wants to send or receive
something over or from the network. At this point you have already a notion
about the network itself. From an application developer perspective you don't
care about this (sockets and so on), you basically only want to request or
share data.

From the caller perspective, what's so different between sending over UDP than
sending over raw IP? Even POSIX socket API allows that. As a sender I want to
specify the destination and the protocol (for both cases it should IMO be
possible to specify a best effort default).

My point was, that I don't see how it makes sense to design one API that can be
used for this purpose *and* protocols on top.
 
> My point is that something like
> 
> ---
> udp_socket_t s;
> udp_bind(&s, address, port);
> 
> udp_read(&s);
> ---
> 
> should be available. If the stack below is netapi based, then those
> calls should map to netapi calls. If not, whatever.

Sure, from the caller perspective you don't care what's happening inside the
stack, but what's so wrong in having the same API at all layers, i.e. inside
and on top of the stack? (Assuming that it can be implemented without (or
very, very, very little overhead.)

I'm not say that netapi is necessarily the API, we want to use on top, and I
agree with you, Kaspar, that we should look very carefully at it and eliminate
any hard dependency to threads or the packetbuffer and so on. But I agree with
Martine, that we shouldn't discard the idea of using netapi for this so
quickly.

Remember, netapi is very, very young. It's a good point in time to change it
*now*, in order to make it fit all our needs. If it turns out to be
impossible, well, then we have to look for something else.

> My first mail explains why I think that POSIX sockets are not suited for
> this.

And I think, there we all agree.

Cheers,
Oleg
-- 
/*
 * We used to try various strange things. Let's not.
 */
        linux-2.2.16/fs/buffer.c
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.riot-os.org/pipermail/devel/attachments/20150508/2e630bf2/attachment.sig>


More information about the devel mailing list