Socket API

[thejpster]

Having worked with a few different modems lately (nRF9160, Quectel BC68, ESP8266) I note they all have APIs to open sockets, and read/write, etc, but they're all different. The nRF9160 uses a BSD-like library, the BC68 uses AT+NSOCR AT commands while the ESP8266 uses AT+CIPxxx AT commands.

I wonder if we could implement some traits for:

• An object which lets you open UDP sockets
• An object which lets you open TCP sockets
• A socket object, which lets you read, write, poll, flush, close, etc (so like the core::io traits we don't yet have I guess, with some extra functions)

We can then write, for example, an HTTP client which works on desktop Linux (we'd have an implementation which uses std::net / mio), or an embedded system with an ESP8266 plugged into a UART, or an embedded sytem with a BC68 plugged into a UART, or on an nRF9160.

Does anything like this exist? If not, I'll see if I can knock up a prototype.

[MathiasKoch]

Did you reach any conclusion on this?

I would be very interested in this exact thing! I am currently writing driver crates for the entire uBlox wifi series of host-based (AT command) devices and the uBlox GSM host based devices, both of which could benefit greatly from implementing a common trait for networking on TCP and UDP sockets.

They are both already based on the only requirement being an embedded-hal layer beneath, as well as a common AT parser crate.

I would end up using MQTT ontop of TCP, and am planning on using the mqtt-rs crate, which could also benefit from OP's suggestion of a shared socket layer.

[ryankurte]

How about we start with a network-hal package? Given it's kindof a different level of abstraction / function I think it'd make sense to have different crates (and I've just done this with a radio hal).

And this could either be outside the WG and transferred later, or created here depending on what people favour?

[MathiasKoch]

I think that would be a great start!
Just out of curiosity, how do you define a radio? Do you have any examples? It looks good though, and if we can make something similar for network, i think it would be of great benefit to the community, now that we start seeing more and more network driver crates popping up.

[ryankurte]

how do you define a radio? Do you have any examples?

Yeah good question, the abstraction I've focused on is for digital packet radios, where you send and receive messages that are byte arrays, which ime you can implement most other simple protocols on top of. Much lower level than say, a WiFi modem that takes AT commands, but, hoping to extend it up enough that BLE and LoRaWAN etc. can be built on it easily.

A few examples:

• ryankurte/rust-radio-sx127x
• ryankurte/rust-radio-sx128x
• ryankurte/rust-radio-at86rf212

On the network-hal front, it's probably also worth looking at smoltcp.

[MathiasKoch]

Cool! Great work!

Regarding the smoltcp i do agree that it is worth both mentioning and looking at, but it seems to me like it is hard to use for host-based devices where SSL and the TCP/IP stack is offloaded to a co-processor, like in the AT cases.

Perhaps a network-hal could be more like the embedded-hal where it is just a number of high level traits, that could then be implemented both by my AT based devices, other networking crates and the smoltcp stack?

[thejpster]

Here's what we call a "starter for ten".

https://github.com/thejpster/embedded-nal