search

firepear / petrel

It's like SQLite, but for networking
MIT License
20 stars 1 forks source link

server per-connection configuration #71

Open firepear opened 4 months ago

firepear commented 4 months ago

there are cases where at least certain portions of a server's configuration should be per-connection rather than per-server. this dovetails nicely with other changes to petrel, the client, and the server itself.

to do this though, there needs to be a way to inject that configuration. the reasonable place to do it is inside sockAccept in server/net.go, but it could also be in a function called from there.

my thoughts on this so far are that clients should be able to identify themselves in some way, and then the server should be able to look them up in some way, and the configuration should then happen (a lot of petrel.Conn configuration is applied per-operation rather than at instantiation so that's convenient).

firepear commented 4 months ago

Tickets #70 and #72 need to happen first.

Once you have a handle on open conns, rather than them only existing, anonymously and immutably, inside goroutines spawned by the Listener, you can change whatever you'd like about them, at any point in time. This means configuration doesn't have to happen while we're still inside whatever initial-connection-handshake thing is implemented. It can be driven by the app, and it can happen after the app handles authentication, etc., etc.

Petrel not having to be concerned about any of that is correct and a huge win.