|
|
@@ -0,0 +1,80 @@
|
|
|
+Socket creator API
|
|
|
+==================
|
|
|
+
|
|
|
+This API is between Boss and other modules to allow them requesting of sockets.
|
|
|
+For simplicity, we will use the socket creator for all (even non-privileged)
|
|
|
+ports for now, but we should have some function where we can abstract it later.
|
|
|
+
|
|
|
+Goals
|
|
|
+-----
|
|
|
+* Be able to request a socket of any combination IP/IPv6 UDP/TCP bound to given
|
|
|
+ port and address (sockets that are not bound to anything can be created
|
|
|
+ without privileges, therefore are not requested from the socket creator).
|
|
|
+* Allow to provide the same socket to multiple modules (eg. multiple running
|
|
|
+ auth servers).
|
|
|
+* Allow releasing the sockets (in case all modules using it give it up,
|
|
|
+ terminate or crash).
|
|
|
+* Allow restricting of the sharing (don't allow shared socket between auth
|
|
|
+ and recursive, as the packets would often get to the wrong application,
|
|
|
+ show error instead).
|
|
|
+* Get the socket to the application.
|
|
|
+
|
|
|
+Transport of sockets
|
|
|
+--------------------
|
|
|
+It seems we are stuck with current msgq for a while and there's a chance the
|
|
|
+new replacement will not be able to send sockets inbound. So, we need another
|
|
|
+channel.
|
|
|
+
|
|
|
+The boss will create a unix-domain socket and listen on it. When something
|
|
|
+requests a socket over the command channel and the socket is created, some kind
|
|
|
+of token is returned to the application (which will represent the future
|
|
|
+socket). The application then connects to the unix-domain socket, sends the
|
|
|
+token over the connection (so Boss will know which socket to send there, in case
|
|
|
+multiple applications ask for sockets simultaneously) and Boss sends the socket
|
|
|
+in return.
|
|
|
+
|
|
|
+Caching of sockets
|
|
|
+------------------
|
|
|
+To allow sending the same socket to multiple application, the Boss process will
|
|
|
+hold a cache. Each socket that is created and sent is kept open in Boss and
|
|
|
+preserved there as well. A reference count is kept with each of them.
|
|
|
+
|
|
|
+When another application asks for the same socket, it is simply sent from the
|
|
|
+cache instead of creating it again by the creator.
|
|
|
+
|
|
|
+When application gives the socket willingly (by sending a message over the
|
|
|
+command channel), the reference count can be decreased without problems. But
|
|
|
+when the application terminates or crashes, we need to decrease it as well.
|
|
|
+There's a problem, since we don't know which command channel connection (eg.
|
|
|
+lname) belongs to which PID. Furthermore, the applications don't need to be
|
|
|
+started by boss.
|
|
|
+
|
|
|
+There are two possibilities:
|
|
|
+* Let the msgq send messages about disconnected clients (eg. group message to
|
|
|
+ some name). This one is better if we want to migrate to dbus, since dbus
|
|
|
+ already has this capability as well as sending the sockets inbound (at last it
|
|
|
+ seems so on unix) and we could get rid of the unix-domain socket completely.
|
|
|
+* Keep the unix-domain connections open forever. Boss can remember which socket
|
|
|
+ was sent to which connection and when the connection closes (because the
|
|
|
+ application crashed), it can drop all the references on the sockets. This
|
|
|
+ seems easier to implement.
|
|
|
+
|
|
|
+The commands
|
|
|
+------------
|
|
|
+* Command to release a socket. This one would have single parameter, the token
|
|
|
+ used to get the socket. After this, boss would decrease its reference count
|
|
|
+ and if it drops to zero, close its own copy of the socket. This should be used
|
|
|
+ when the module stops using the socket (and after closes it).
|
|
|
+* Command to request a socket. It would have parameters to specify which socket
|
|
|
+ (IP address, address family, port) and how to allow sharing. Sharing would be
|
|
|
+ one of:
|
|
|
+ - None
|
|
|
+ - Same kind of application
|
|
|
+ - Any kind of application
|
|
|
+ And a kind of application would be provided, to decide if the sharing is
|
|
|
+ possible (eg. if auth allows sharing with the same kind and something else
|
|
|
+ allows sharing with anything, the sharing is not possible, two auths can).
|
|
|
+
|
|
|
+ It would return either error (the socket can't be created or sharing is not
|
|
|
+ possible) or the token. Then there would be some time for the application to
|
|
|
+ pick up the requested socket.
|
Michal 'vorner' Vaner