Opinions Wanted: "Auto Responders"?

[jamesmunns]

There are certain tasks we probably want the netstack to "automatically" handle. Off the top of my head, this could include:

• Device pings
• Device discovery requests, e.g. "Who is out there?"
• Service discovery requests, e.g. "Who has service X? Tell address Y"

The current capability for this requires users to spawn a worker task/socket for each of these. This allows users to define which ones they want to support, but might have some boilerplate: if we have 4-5 "minimal functionality" services, that means all users need to set that up.

I'll explore some potential options of how we could handle this below.

[jamesmunns]

Callback-style handlers

One option would be to offer some kind of callback-style handlers that can immediately handle some kind of request. This could be passed in as a list of function pointers, that would have some kind of access to the inner portion of the netstack, and allow for immediately handling requests, without having an explicit socket for this.

We would need to define some kind of interface for this, and define where in the dispatching stage it occurs, for example BEFORE searching for sockets, or AFTER searching for sockets.

This could be difficult, because we need to define what kind of access these handlers have, they may want to query the list of sockets, or the profile/interface. I could also see wanting to be generic over the Profile, or even having some kind of context.

[jamesmunns]

We could possibly tie the handlers to the Profile, and have the profile provide the callbacks?

[jamesmunns]

One "meh" aspect of this, the handlers will need to have an interface similar to the socket vtable, as they could potentially handle ty, bor, or raw packets. This means that that autohandler list is more like a vtable list than a simple list of fn pointers.

This essentially means duplicating the "vtable glue" for handling messages, and means that anyone writing an auto-handler has to deal with it, which is a bummer.

[jamesmunns]

A single many-service task

Another option would be to provide an async fn that handles some subset(s) of baseline functionality, and open a socket for each of them. This fn could then select on all of the sockets, and handle their requests.

This still leaves some question on how to access the information, and does still consume N sockets for handling this.

Users would then need to spawn this function to do the handling, but it would reduce the boilerplate a bit.

[jamesmunns]

Status Quo: Just provide handler tasks for this

One option would be to just provide async fns for automatic handling. This means we can re-use existing socket infrastructure, at the cost of asking users to spawn a task/tasks to handle this, and using up ports to do so.

[jamesmunns]

I'm leaning towards this to start with, if we want to then lift the handlers into auto-responders, we can do that.

[cramt]

i think this is generally the most composable option. so atleast having this as a fallback always is a good idea. Maybe a happy path abstraction ontop is just a decl macro maybe?