Can server and client each initiate communication and send commands on same port?

I have a server and a client app, my server listens on port 10015 and a client which sends commands to that port. Currently both are running on the same machine, but in the future the goal will be to have running on different machines. I have this part working right now.

What I need to do next is have my server send commands to my client as well. So I thought I could just re-use my code from my server in my client to listen on a port.

But I am not sure that is the best way to do it. Suggestions?

When I first tried this, I ran my client app first, and it sent the command to itself. My server app failed to bind to the port (I assume you can only have one process listening on a given port? )

Question 1) How can the server send commands to the client? Do I have to create make the server-->client communication on port 10015 and client--->server on a different port like 10016?

Question 2) When I send a command from client-->server with send(), what's the best way to receive an ACK to that specific command? If I dont need to send any data back is there a way to just get an ACK automatically when the packet is received by the server?

I am currently doing this for every command I want to send :

create开发者_JAVA技巧 socket()
conenct() to socket
send() packet
then call recv() to receive any data 
then shutdown() connection
and closesocket() at end

not sure if there's a better way to do it? I am expecting to send anywhere between 1-10 commands per sec when my app is busy.

thanks, I am new to this networking applications, so any help is greatly appreciated.

Edit after reading some comments:

I am using TCP protocol. When I said ACK, I meant I just wanted some acknowledgement from the other app that the command had been received and processed without errors

Typically the way this is done is as follows:

1. The "server" binds a socket to a specified port -- it looks like that'd be 10015 for you.
2. The "client" uses an ephemeral port for its outgoing transmissions
3. If the server is to respond to the client, it sends a message from it's bound port (10015) to the source port of message #2, the ephemeral port.

On the server:

If you are using UDP, you can simply copy the sockaddr structure that was set during recvfrom() into the sockaddr structure that you're passing to sendto().

If you are using TCP, the socket file descriptor returned by accept() can be used in send() to send response traffic to the client.

My favorite C Sockets reference is the free and available online Beej's Guide to Network Programming.

Your question implies that you're using UDP. This requires the client to be listening on a port (vs. two-way communication on a socket in TCP).

You are correct, they both can't use the same port. You need to have the client listening on one port, and the server another if they trying to bind to the same interface on a single machine.

The answer to Question 2 is ... you're using UDP. You have to explicitly send something back. You should be using recvfrom() in the server; the information for where to send the ack is stored in the struct sockaddr *src_addr you pass in.

Edit after re-reading: If you're not trying to use UDP ... you just connect to the server with the client and communicate back and forth over the socket. Your client doesn't listen to anything. The tutorial here should help.

They can listen at the same port as long as they are on different hosts.

You are correct in that two applications cannot both listen on the same port, on the same address¹. If you want your client to have its own listening socket, then it should use a different port number - your suggestion of 10015 for the server and 10016 for the client is fine.

However - you likely do not need the client to have its own listening socket. TCP connections are full-duplex - your server can simply send requests to the client back down the same connection that the client uses to send requests to the server, as long as that connection is still open.

As for question 2, the best and only way to receieve a useful ACK is to have your application send it itself - normally, after it has executed the command.

As for your current method of sending a command, where you setup and tear down a new connection for every command, this is highly inefficient (and also prevents you from using the same connection as a back-channel from the server to the client). Instead, you should keep the connection open and use it to send multiple commands.