Dedicated RIOT Network Stack Meeting

Development archive
#1

Dear RIOTers,

In the developer & maintainer meeting this week a discussion arose about an upcoming refactor of the network stack. As a result we concluded to hold a dedicated and prepared meeting to discuss this topic in a bigger circle.

The topics will be to review our current network stack architecture and discuss possible solutions to   * optimisation (especially memory consumption, buffer management)   * functional restructuring   * how to deal with multiple network interfaces   * design of an interface between radio driver and MAC protocol

Below [1] the compulsive poll to find a date. The meeting will most probably take place at FU Berlin but remote participation will be provided for those who cannot attend in person.

Best, Thomas

[1] http://dudle.spline.de/RIOT-net-dev/

#2

Hi, could we add a week more, since next week will be absolutely not possible for me to attend such meeting (except maybe friday morning).

Best, Martine

#3

Hi Martine,

the poll already includes two weeks, you mean the week July 14th-18th?

Thomas

#4

Hi,

I was just last night having a discussion with some Broadcom Engineers - apparently they make the network hardware that 99.9995% of all internet traffic goes through.

The engineer was explaining how ChibiOs was a great OS for embedded systems and networking. I'm not yet totally convinced of that just yet but the discussion was fairly interesting.

Lot's of operating systems are still based on old-school techniques.

One thing I'd like to propose is exposing a packet-callback interface in C in addition to a Poll+Block-Wait approach.

So that, when a packet is received, a callback to the user-code is fired and an address is passed to the packet. Of course, due to memory constraints the packet won't be copied to user-memory-space it will still reside in the os-memory-space.

In terms of setting up all network send/receive, I'd suggest having one packet framework that can deal with all types of packets. Essentially they are all the same, but history makes us not think this way.

What does change is the setup parameters that are required to set up each type of device/protocol. Setting up a UDP transfer is going to need different parameters to an nrf24L01+ - but after that things should be the same.

Even in Linux, in the end, everything becomes a file-handle and you have to use those. But I'm not necessarily advocating doing that - however it does work well in Linux, but Linux is 'bigger'. So don't necessarily copy that.

Maybe some C++ is used to do this or maybe not. It doesn't matter.

I'd really like to test all this on the native Linux port. I'm really hoping that Sockets/UDP and MQTT can be incorporated into the packet-protocol. That way I can just test things from my desktop easily :slight_smile:

If we can set up a packet-relay on a Raspberry-Pi or Linux box that would be really convenient.

Regards

David

#5

Yes.

#6

Ok, I extended the poll by one week.

Best, Thomas

#7

Thank you!

Best, Martine

#8

Hi, I’d be interested in listening to the discussions, if that’s okay with you. However, i won’t be in Berlin on most of the dates– would it be possible to participate/listen remotely as well?

Cheers, Lotte

#9

Hi Lotte,

I'd be interested in listening to the discussions, if that's okay with you. However, i won't be in Berlin on most of the dates– would it be possible to participate/listen remotely as well?

sure, we'll provide Skype and POTS participation facilities.

Cheers, Oleg

#10

Dear RIOTers,

reading the poll, we will hold the network stack meeting on Tuesday July 15th at 10am at FU Berlin in room 148.

For remote participation via Skype please let us know, so we can invite you to the conference call.

Best, Thomas

#11

I would be interested in attending remotely.

I read the wiki page dedicated to the topic and have some comments.

With respect to implementing JSON from scratch, I'm not sure this should be a high priority. I do respect the fact that there are people with the skills to do a good job of writing that.

Some of the processors, for example MSP430, may struggle for enough flash/RAM to have a JSON encoder/decoder.

As further explanation, lot's of the small processors are probably going to be used as remote nodes. To either send information or receive commands.

I'm suggesting that a good priority might be to implement a single TCP/IP socket (client) connector interface on the native port.

This comes closest imo to replicating the typical use case of Riot and the small-remote-device.

On the 'server', maybe use a python-socket-server program of less than 100 lines to round-robin.

Once the generic packet send/receive interface is done, it will be able to be implemented on other transmission devices.

Regards

David

#12

Hi David,

#13

Dear RIOTers,

due to a clash of appointments this meeting was rescheduled to Monday July 14th at 4pm CEST.

Sorry for the inconvenience.

Best, Thomas

#14

Quoting Thomas Eichinger <thomas.eichinger@fu-berlin.de>:

Hi David,

I would be interested in attending remotely.

Could you send me/us your Skype name so we can invite you to the conference call?

Best, Thomas

David.lyon. clixx.io

That would be great thanks.

#15

Hey folks,

do you think it's possible to relocate the meeting to Agora or another non-university spot? However, at Agora I would vote for reserving a meeting room/office instead going to the Café again. Does anyone care to organize this?

Cheers, Oleg

#16

+1 for Agora

Best Christian

#17

Morning,

is the convergence towards a meeting place done?

Best Fabian

#18

Hi,

As far as I know out might turn out to be at agora at 18:00.

Cheers, Ludwig

#19

Hi, Can someone give me the address please? I will come directly to the venue.

Regards, Martine

#20

Agora Collective

4,8

8 Erfahrungsberichte

Co-Working-Fläche

Mittelweg 50, 12053 Berlin

030 60407311