Re: [riot-devel] conn f2f (+ remote) meeting
Hi,
2016-08-17 19:28 GMT+02:00 Oleg Hahm :
> Hey folks,
>
> On Mon, Aug 15, 2016 at 04:11:48PM +0200, Martine Lenders wrote:
> > as promised: here is the agenda for the meeting next Wednesday:
> > http://yourpart.eu/p/netapp-api-riot
>
> thanks for the protocol, but is a bit hard to follow as a non-attendee.
> Could
> anyone come up with a short summary and, in case you concluded on a
> particular API, could present how it should look like?
already reworked it to a more readable form (just waited for some comments
by the attendees) [1]
TL;DR:
* reworked API will be called sock not conn to keep them distinguishable
when talking about it / porting it
* UDP/IP will have a somewhat reduced function set (convenience functions
are dropped)
* TCP will have a queue type for listening
* create functions for all will receive a flags parameter so options that
need to be done before binding can be passed
For reference I will adapt #5533 today
[1]
https://github.com/RIOT-OS/RIOT/wiki/Application-Layer-API-Meeting-on-August-17,-2016
Cheers,
Martine
Application Layer API Meeting 1
===
Agenda
--
1. Agenda Bashing
2. Goals and Priorities
3. Naming of the API
4. Detailed API-discussion:
1. IP-based transport layer with datagram-based communication (IP raw /
UDP)
2. IP-based transport layer with sequence-based communication (TCP)
5. Future extension
1. Asynchronous event handling: External vs. native support
2. Options
3. Per packet configuration
Meeting Details
---
### Attendees
* Alexander Aring [eintopf]
* Cenk Gündoghan
* Kaspar Schleiser
* Martine Lenders (Chair)
* Peter Kiezmann
* Simon Brummer
### Protocol
* Peter
* Simon
Goals / Priorities
--
1. No need for dynamic memory allocation
2. User friendliness
3. Simplicity
4. Efficiency (at both front- and backend)
5. Easy to implement for network stacks / portability
Naming of the API
-
* Pro `conn:
- Name was picked to differ from the old sockets because it isn't socket
* Con `conn`:
- `conn` basically behaves like sockets (just look at the
function-calls)
- New-comers might search for "something like sockets" anyway
- Name change would show API change better and ultimately would be less
confusing for users of `conn`
* Result: `sock` as name for the new API
* Side discussion: Documenting API changes
- Wiki does not work, because it is forgotten after creation
- Documentation via a dedicated README file is better
Detailed API-discussion
---
### IP-based transport layer with datagram-based communication (IP raw /
UDP)
- [Reference API][conn_udp]
- `sock_udp_create`/`sock_udp_close` good as is
- Getter (`sock_udp_get_local`/`sock_udp_get_remote`) stay because they
don't
hurt and are needed for socket wrapper implementation
- Setter: easier and more convenient to create new `sock` instead
- `sock_udp_recv` and `sock_udp_recvfrom`:
* Order of parameters of `sock_udp_recvfrom` confusing with that name
* Static inline in API definition not nice
* Result:
+ original `sock_udp_recv` should be removed
+ `sock_udp_recvfrom` renamed to `sock_udp_recv`
- `sock_udp_send` and `sock_udp_sendto`:
* There are three sensible use-cases for `sock_udp_sendto`
1. `sock != NULL`, `sock` is connected, and `remote == NULL`
2. `sock != NULL`, `sock` is connected, and `remote != NULL`
3. `sock == NULL` and `remote != NULL`
* Currently only convenient function for 1., why not for 3.?
* Also again: static inline in API definition
* Result:
+ original `sock_udp_send` should be removed
+ `sock_udp_sendto` renamed to `sock_udp_send`
### IP-based transport layer with sequence-based communication (TCP)
- [Reference API][conn_tcp]
- [Simon wants a `sock_tcp_listen` function][conn_tcp_listen]
- Kaspar: two object types requiered
- One representing a connection,
- One representing a listening socket
- split `sock_tcp_create` and `sock_tcp_close`:
~~
{.c}
/* Connections:
* (Only port required for local; and even that only in special cases) */
sock_tcp_connect(sock_tcp_t *sock, sock_tcp_ep_t *remote, uint16_t
local_port);
sock_tcp_disconnect(sock_tcp_t *sock);
/* Listening Socket / Queue */
sock_tcp_listen(sock_tcp_queue_t *queue, sock_tcp_ep_t *local,
sock_tcp_t[] queue_array, unsigned queue_len);
sock_tcp_stop_listen(sock_tcp_queue_t *queue);
~~
- later additions: something like `tcp_listen_dynamic`, as as passing the
whole
queue as parameter is not suitable for servers with lots of RAM
(portability)
- `sock_tcp_accept` needs adaptation to new object types:
`sock_tcp_accept(sock_tcp_queue_t *queue, sock_tcp_t **sock)`
- rename `sock_tcp_send`/`_recv` to `sock_tcp_write`/`_read`; better
s
Re: [riot-devel] conn f2f (+ remote) meeting
Hey folks,
On Mon, Aug 15, 2016 at 04:11:48PM +0200, Martine Lenders wrote:
> as promised: here is the agenda for the meeting next Wednesday:
> http://yourpart.eu/p/netapp-api-riot
thanks for the protocol, but is a bit hard to follow as a non-attendee. Could
anyone come up with a short summary and, in case you concluded on a
particular API, could present how it should look like?
Cheers,
Oleg
--
printk("; corrupted filesystem mounted read/write - your computer
will explode within 20 seconds ... but you wanted it so!\n");
linux-2.4.3/fs/hpfs/super.c
signature.asc
Description: PGP signature
___
devel mailing list
devel@riot-os.org
https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Condition Variables
Hey, On 08/16/2016 09:49 PM, Sam Kumar wrote: > If not, I want to learn if there is another structured way to > block a thread until an event, that I should use instead. maybe thread_flags work for your use-case. Kaspar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Condition Variables
Hi Sam, in its core RIOT only provides a small and efficient mutex implementation. Condition variables are provided within the POSIX wrapper [1], specifically in the the pthread part [2]. To get an idea how use the provided condition variables you can have a look in our tests for it [3]. But as Simon stated you should consider if using the Message passing possibilities of RIOT could have the desired effect, since using the POSIX condition variables in RIOT also comes with a certain overhead. Best regards, Martin [1] http://riot-os.org/api/group__posix.html [2] http://riot-os.org/api/group__pthread.html [3] https://github.com/RIOT-OS/RIOT/tree/master/tests/pthread_condition_variable Am 08/17/2016 um 11:21 AM schrieb Simon Brummer: Dear fellow TCP implementor, The common way implement something like this in RIOT is Message passing. Your thread simply blocks by calling msg_receive() until it received a message from another thread. As soon as you receive a Packet, send a message to the via msg_send() function to wake the blocked thread. Cheers Simon Brummer Am Dienstag, den 16.08.2016, 12:49 -0700 schrieb Sam Kumar: Hello, I was looking at the synchronization primitives in RIOT OS. I noticed that there is a mutex implementation, but I was unable to find a condition variable. I am currently porting the TCP logic from the FreeBSD operating system to RIOT as part of the research work I am doing. I am implementing the "conn" API for TCP, and I need to be able to block the current thread until a packet is received, to implement some of the functions. I read the IPC implementation (msg.c), which also has a blocking API, and saw that it interacts with the scheduler manually in order to block and resume threads. Before I did the same thing for the conn API (or perhaps implement/contribute my own condition variable), I wanted to ask whether there are condition variables for RIOT, in case I was just looking in the wrong place. If not, I want to learn if there is another structured way to block a thread until an event, that I should use instead. Thanks, Sam Kumar ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] conn f2f (+ remote) meeting
Hi, the meeting will start at 1pm sharp (so please set-up your mumble well before that, if you haven't yet). Those of you who like to join me at FU Berlin: I'll be in office 105. Everyone else: the mumble server to connect to is at riot-labs.de:64738, the password is "riot". Regards, Martine 2016-08-16 15:26 GMT+02:00 Peter Kietzmann : > Mi Martine, > > no objections from my side. I would like to join virtually. > > Regards > Peter > > > Am 16.08.2016 um 14:12 schrieb Martine Lenders: > >> Hi, >> are there any objections to have the meeting for the Berlin people at FU >> and let the rest join via Mumble [1]? >> >> If not: please state if you like to join the meeting (physically or >> virtually) so I can plan for a room if need be or expect you in the >> virtual >> room. >> >> Cheers, >> Martine >> >> [1] https://wiki.mumble.info/wiki/Main_Page >> >> 2016-08-15 16:11 GMT+02:00 Martine Lenders : >> >> Hi, >>> as promised: here is the agenda for the meeting next Wednesday: >>> http://yourpart.eu/p/netapp-api-riot >>> >>> Cheers, >>> Martine >>> >>> 2016-08-11 15:33 GMT+02:00 Martine Lenders : >>> >>> Hi all, we finally want to discuss the overhaul of conn next week. The meeting will be held on Wednesday next week (August 17th) at 1pm (UTC+0200). Remote participation will be possible, we'll try to find a tool that everyone is comfortable with. I'll provide you with an agenda for the meeting until Monday and post it here. For reference until then (if you want to read through it) there is the discussion in PR 5533, with some rough summary of the discussion so far in [1]. For reference here is Kaspar's sock API, which was also discussed and taken as basis for some of the work in the PR. Cheers, Martine [1] https://github.com/RIOT-OS/RIOT/pull/5533#issuecomment-237865337 [2] https://github.com/kaspar030/sock >>> >>> >> >> >> ___ >> devel mailing list >> devel@riot-os.org >> https://lists.riot-os.org/mailman/listinfo/devel >> >> > -- > Peter Kietzmann > > Hamburg University of Applied Sciences > Dept. Informatik, Internet Technologies Group > Berliner Tor 7, 20099 Hamburg, Germany > Fon: +49-40-42875-8426 > Web: http://www.haw-hamburg.de/inet > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel > ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
Re: [riot-devel] Condition Variables
Dear fellow TCP implementor, The common way implement something like this in RIOT is Message passing. Your thread simply blocks by calling msg_receive() until it received a message from another thread. As soon as you receive a Packet, send a message to the via msg_send() function to wake the blocked thread. Cheers Simon Brummer Am Dienstag, den 16.08.2016, 12:49 -0700 schrieb Sam Kumar: > Hello, > I was looking at the synchronization primitives in RIOT OS. I noticed > that there is a mutex implementation, but I was unable to find a > condition variable. > > I am currently porting the TCP logic from the FreeBSD operating > system to RIOT as part of the research work I am doing. I am > implementing the "conn" API for TCP, and I need to be able to block > the current thread until a packet is received, to implement some of > the functions. > > I read the IPC implementation (msg.c), which also has a blocking API, > and saw that it interacts with the scheduler manually in order to > block and resume threads. Before I did the same thing for the conn > API (or perhaps implement/contribute my own condition variable), I > wanted to ask whether there are condition variables for RIOT, in case > I was just looking in the wrong place. If not, I want to learn if > there is another structured way to block a thread until an event, > that I should use instead. > > Thanks, > Sam Kumar > ___ > devel mailing list > devel@riot-os.org > https://lists.riot-os.org/mailman/listinfo/devel ___ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
