4 ms·
Good to learn a bit of history about TCP. It always felt weird developing RPC layers on top of TCP cause requests and responses end up tied to the underlying s
by iambvk 4y ago
Good to learn a bit of history about TCP.
It always felt weird developing RPC layers on top of TCP cause requests and responses end up tied to the underlying socket -- which doesn't need to be the case ever.
- AceJohnny2 4y agoHow else would the kernel know to which application it should route a response?
- cjsplat 4y agoDestinations can be described in the packet headers. That is how the current systems work.
- iambvk 4y agoDestination port number should be sufficient. For example, imagine if there are two sockets established between server and client processes (due to multiple ips or roaming, time lags, etc.), then in theory, request received from one socket could be responded through another socket. From application pov it doesn't need to care about the socket. We can do this over TCP, but connection-oriented nature of TCP makes this weird.