Should generating the address and secret be separate from creating the socket object?

[emschwartz]

@adrianhopebailie raised the point that we may want to separate the generation of the destinationAccount and sharedSecret from the creation of the socket object.

The two reasons I could see for doing this would be:

1. Different processes could create the credentials and listen for incoming socket connections
2. Socket objects aren't created in memory until the client is connected (this is a weak argument because if someone wanted to DoS the server, they could send one connection packet and then just not send any more)

The downsides of doing this would be:

1. The user of the library needs to connect the context where they create the credentials to the socket object when it is created (for example, to know what limits to set on the socket and to register event handlers for incoming money)
2. Having a separate process creating credentials wouldn't work with dynamic ILP addresses (like mini accounts currently uses)
3. Payment Sockets are different than TCP sockets in that you're not setting up a listener for all incoming connections, but rather you need to specifically create the credentials for each connection. Therefore, it may make more sense to keep the context in which you're creating the credentials together with the socket object, because creating the credentials means you're listening for one specific connection anyway

[adrianhopebailie]

I'd suggest looking at the Socket API closely and understanding why this pattern (which is decades old) is still the most popular primitive in IPC.

Sure, it is much easier to just design an API that does everything in one function than one that is composable but it's then much harder to break it up later if you need to.

On the other hand following widely used patterns is the best way to design for use cases you may not have seen yet.

Payment Sockets are different than TCP sockets in that you're not setting up a listener for all incoming connections, but rather you need to specifically create the credentials for each connection. Therefore, it may make more sense to keep the context in which you're creating the credentials together with the socket object, because creating the credentials means you're listening for one specific connection anyway

I strongly disagree with this. This makes it very difficult to horizontally scale. You CAN setup a listener for all incoming connections and then queue them up and pass them off to different handlers as new handlers become free to process connections.

This is why servers have a backlog and the applications that handles incoming connections calls accept to get the next connection in the backlog.

There are a lot of use cases where separate services will generate new ILP addresses and secrets for clients to connect with (example SPSP servers and invoice servers) but not necessarily be the same service that handles the incoming connection.

Example: I can imagine an invoice server periodically reconciling with the payment receiver to find out which invoices have been paid.