Develop Reference

Windows Service to continuously monitor network server on TCP port

This is my first foray into socket programming. I need some help to get started. Basically, I have a server that sends out status updates on a specific TCP port. I need a client computer to look out for those update messages. I've decided to create a Windows Service in C# that will be installed on the client computer. I can't figure out if the service should be TCP listener (server) or client. Any guidance will be highly appreciated.

Since you already have a server that will send the updates, all you need to do to receive these updates is to create a TCP client on your host. This will serve as the listener, just connect it to the appropriate server's IP and port. Alternatively if you already have a client that connects to the server and just want to intercept the traffic, use something like tcpdump.

Figured it out. This comment from TcpClient Class threw me off:
// Note, for this client to work you need to have a TcpServer
// connected to the same address as specified by the server, port
// combination.

c# Socket.RemoteEndPoint shows different port that I'm using to connect

I've developed a basic console application that will work as server-client. My general workflow will be like, Server starts clients connect to server and once a client send something the server will receive it and send it to ALL clients. Currently I can do this with my codes but my question is when I send back I've tested Socket.RemoteEndPoint and I saw ports like 65xxx. Like my first client had 65020, second 65021 and so go on. I wonder why this happen since I connect with using 9001 port and listen to 9001 port on my computer. I've done a little bit research but couldn't find a solution to my question. Why do I get these port numbers when I use Socket.RemoteEndPoint? It's okay for me since I don't use firewall or anything while I'm testing to even if the clients connects from another ports it's fine by me as long as its works but what if I have a firewall and I open ONLY 9001 port? Will my client-server based programs work then?

So far as the server/firewall on that machine is concerned, what normally matters is the server port. You wouldn't normally apply any filtering based on the client's port, which as I said in a comment, will normally be an ephemeral port. Under most circumstances, client code will make no effort to specify the local port or IP address and will let the OS pick appropriate values.
The Socket class's LocalEndPoint and RemoteEndPoint use "local" and "remote" to mean "from the perspective of the machine on which this code is running", not "who initiated the connection vs who was connected to".
So on the server, LocalEndPoint will give you information about the server end of the connection and RemoteEndPoint will give you information about the client end of the connection. Irrespective of who initiated the connection.

If a client Udp port punches to a server on one port, can I assume it will send from same port if it sends to a different port on the server?

Kind hard to explain so here it is step by step:
Client sends data to Server via Udp. Client port X to server port 3000.
Server uses this communication to set up a UdpClient to listen for this specific client on port 3001 for client port X.
Client then sends data as needed on local port X to server port 3001.
Everyone is happy.
My question is: Can I assume that if the client is communicating to the server behind a NAT and it punches a udp port, that if it communicates to ANOTHER port on the same server that it will use the same port?
[Edit: formatting]

No you can not assume that. It may happen or it may not happen, it is up to the writers of the software of the NAT firewall the client is punching through.
A complex software may detect that you are talking to the same server but a different port and reuse the outbound port, but simpler software (the kind you would frequently see on home routers) may be "dumber" and just use a new randomized port per connection.

How to send back to a UDP source address?

I have a question concerning communication between a server and a client using UDP. I'll first explain what I'm trying to do.
The client sends a message to the server using a random UDP source
port to a static server UDP port (11000).
The server then learns the clients sending port.
Then the server sends a message back to the client using another
random port to the clients sending port.
The problem is that the server can only send back if clients random port is forwarded on the router. I don't know if it's possible but shouldn't the server be able to send back to the the client using the same port the client used to send without forwarding the port? I also read about hole punching but if I understand correctly it's only needed when you want peer-to-peer connection. The server had a static ip. I'm trying this in C#.
I hope the question is clear. Thanks in advance!
EDIT: Information about the setup:
The client is a game client which should be able to connect to the server from almost any location. (It's currently running on my home pc). The server is located at school and has a static IP. All ports on the server are open and the server is also used for ftp and has a server running that uses TCP. Those things work fine. TCP works because it creates a connection and the server uses that connection to send back to the client. The problem with UDP is that the server can't send back to the client because UDP is connectionless.
Like I said if I open ports on the client everything works great. But my question is: How do I send back to the client without opening ports on the client? Most games don't require you to open ports. So is there any possibility to either send back without port forwarding or can I open a port using C#?
EDIT2: Found the answer
I found the answer. To communicate you need to use the same UdpClient to both send and receive. I was using one to send and one to receive.
Degor

Socket programming: The Server

Ok so I've been trying to teach myself some socket programming. I wrote myself a little C# application with an async server and I understand most of it, except for the following:
So the server has a port it listens on for connections then when it receives a connection it creates a different socket to do the communication on. This it what I dont understand... How does the communication happen between the client and the server when in theory the client has no idea what port has been elected for this new connection?
Thanks for all your answers
Edit: As far as I understand the listening thread listens on the default port, but all messages are then handled on a different socket for each client?
Edit Again: Some how you guys are misunderstanding my question. I understand normal socket communication. My problem is with an async server where the listening socket is different from the connecting socket. Ie.
Server listens on default port
Client attrmpts to connect.
Server receiver request.
Server then creates a communication socket between client
and server and continues listening
on the default port.
My problem is at the last step. How does the client now know how to communicate on the new socket?
Here is some sample code
http://msdn.microsoft.com/en-us/library/5w7b7x5f.aspx

Although this question was posted over a year ago, I belive it is worth trying to clarify (or confuse?) it a bit more.
"How does the client now know how to communicate on the new socket?" - The client is not aware that a new socket was created. It simply keeps on sending data (packets) to the same port.
However, this gives rise to another question: How does the server know which data comes from which client? - Thanks to the TCP and IP protocols the server knows both the address of the client and the source port from which the packets were sent. With this information the server can receive packets from multiple clients and multiple (client) ports and route them to the correct socket. For this question, think of server sockets as filters: when packets are received from client X - port Y then route them to socket Z.
"...does it now know it needs to communicate on a different socket/port?" - This is a frequent source of confusion. When a new socket is created on the server to receive packets (after the connection has been established) it does not use a new port, it keeps on using the original port number. The entire socket creation process on the server side is transparent to the client. The client never knows (nor does it need to know) that a new socket was created to handle its packets.
Google TCP header for more information.
Hope this helps someone.

When the client connects to the server, it selects the port to connect to. The client also includes a port that it will receive responses on. This is typically a randomly selected port, but it's possible for the client to override that.
Think of it like a phone call. When you call someone, there is the phone number you call, and you also have a phone number. even though you both talk to each other, both phone numbers are in use.
That's not a perfect analogy, since phone numbers are more like IP addresses and trunk lines need not have an originating phone number in all cases, but the same concept applies.
Simply put, the TCP protocol requires an originating port and destination port as well as originating ip address and destination IP. When packets are sent in either direction, the apropriate IP/Port is used either way.

Actually the new connection use the same port. A server listen on a specific port for incoming connection, anytime it receives connection request from client, the server accept it and create a new thread to process the request. And then continue to listen on that port.

Definitions
Client: The socket at the remote machine that is connecting to the server
Server: The socket that is waiting for connections on the server
ServerClient: The socket which is communicating with the Client
Answer
I couldn't find any details about how the ServerClient port is transfered to the Client after the Server has accepted it. But it's most likely transfered in the handshake. Feel free to read RFC793 if you want to know more.
I wont go through the details, but you can read about passive connects to get more information about how listener sockets work at lower levels. But basically the purpose of listener sockets (Server) is only to accept sockets (ServerClient).
The port that the ServerClient uses is assigned by the socket implementation in the operating system and is nothing that you can control. All you need to know is that the each connected ServerClient will get it's own port and it's transfered to the Client during the (threeway) handskake (I think ;))