0
votes

After server, which is listening on port X, receives a request from the client, can it send response from a different process and a socket with sendto call. Please note that the client also sends request with sendto (server address) call.

Here are the steps:

  1. server opens a socket and binds it to IP address (a.b.c.d) and port (x)
  2. client opens a socket and binds it to IP address (k.l.m.n) and port (z) and sends request to server with sendto call.
  3. Server (in different process) opens a socket and binds it to IP address (a.b.c.d) and port (y)
  4. server sends response from above socket to client with sendto

Both client and server knows each other ip addresses and port numbers.

I am noticing that client does not receive response when server sends response from a different process. Otherwise, it does.

1
I think you're lost...Ignacio Vazquez-Abrams
"I am noticing that client does not receive response when server sends response from a different process". Isn't the likely reason because of bugs in your code? What you have described is possible if coded correctly. But we can't help you further since you have not shown any code.kaylum
If your socket is TCP oriented, you can spawn a child process and the file descriptor of the accepted connection will be inherited. Then use send() and recv(). But it seems you are using UDP sockets. In UDP sockets, you only create the socket and bind to it. There's no listen()ing port. You then use sendto() and recvfrom(). In your case, you should spawn a child, which already inherited the creation and binding to socket, to recvfrom() the messages sent from client. If you are truly creating, binding and listening on a connection oriented, sendto() ignores the destaddralvits
In summary, you may use sendto() even in connection oriented socket but you need to use recv(). In connectionless oriented socket you can only use sendto() and recvfrom().alvits

1 Answers

1
votes

This can be done but there are some major caveats.

  1. The client must bind the socket and use sendto() and recvfrom() rather than connect()'ing the socket and using send() and recv(). This allows it to receive incoming packets from anywhere as long as they are directed to the IP/Port that recvfrom() is reading on.

  2. If there is a firewall or NAT in the path between client and server, it is likely to block the response since the sending IP/Port does not match the IP/Port that the client originally sent its request to.