Send a message (or packet) to another trusted machine and have it buffer the message until process is ready

Question

I have two trusted machines that are connected, call them 192.168.0.10 and 192.168.0.11. Let's assume both machines are running Linux. Is it possible for me to send a message from 192.168.0.10 to 192.168.0.11 and have 192.168.0.11 buffer that message (for some TTL) until a process on 192.168.0.11 starts listening to the port that message was sent to?

I understand the current state of the world. Assuming I have a C server and if we wanted to have 192.168.0.10 send a message to 192.168.0.11, we would have 192.168.0.11 create a socket, bind that socket to an address and port, listen for connections, accept connections and receive messages using recv. And 192.168.0.10 would create a socket, connect and send using send. I am specifically wondering can the client (in this case 192.168.0.10) send the message before the server (192.168.0.11) starts listening for connections?

Image of what I would like

Answer 1

According to WiKi, "Remote direct memory access (RDMA) is a direct memory access from the memory of one computer into that of another without involving either one's operating system."

This page further says, "... enabling the network adapter to transfer data from the wire directly to application memory or from application memory directly to the wire"

To use RDMA, the applications use a well-defined API to transfer data. This certainly would fit the bill in the sense that "it is possible for to send a message from 192.168.0.10 to 192.168.0.11 and have 192.168.0.11 buffer that message" provided the OS and the network adapters support it. See 1 for the traction RDMA has gained with hardware and software vendors.

Answer 2

Both TCP and UDP messages are delivered to a process listening to a specific port (or port pair). If a datagram is received and no process is listening, it is discarded.

You are describing a publish-subscribe, or otherwise queueing solution that requires storage somewhere. The operating system does not provide these services and you would need to include a message bus or queueing system in your landscape to support this persistence.

For example, what do you expect to happen if the receiving system restarts after receiving a message, but before the process starts to listen?