I coded a server/client application which i ran first locally and then over the internet. Therefore i configured my router that it accepts data on port xxxx and forward it to my machine where my server runs and where it accepts connections from client sockets. So everything runs fine and the clients can send there messages to each other. So now my question is, how is it possible that the server can send data to the clients in other networks where port forwarding isn´t activated but when i try it manually it doesn´t work.
I already tried searching about how the TCP saves IPs and ports and I also looked up how the concept of the Internet/TCP/UDP works but couldn´t find an answer to the question.
So first of all I wanted to know that before I implement my server without port forwarding and it would also be appreciated if you could give code examples for c++ on windows if you have any ideas so that i can establish such connections without port forwarding and extern serverhosts on the internet.
Clint -> NAT (router) -> ... -> NAT (router) -> server
When client sends a message (it can be a connection attempt in case of TCP or just a message if it's UDP), its NAT doesn't block it and remembers which local address:port it's coming from and to which address:port it's going to: [client address:port, server address:port]. When the message hits server's NAT, the NAT knows about your server because you configured "port forwarding" and passes the message to local network. Now, when server sends message back to client and it reaches client's NAT, the NAT checks its internal table, finds a record for this particular server address:port, retrieves client address:port part and passes the message to it. So everything works as expected.
It's why usually when you open your browser and go to some web link, you receive server response with web page without problems despite you are behind NAT.
It's a simplified explanation which omits local/global address:port details.
In my Qt application I am using a peer to peer DBus connection. Server runs on computer A, client on B, connected via DBus TCP/IP connection. Works fine.
I wonder if I can somehow find out whether the server is running and what its IP address is? So far I need to provide the correct address/port in the client.
Both, server and client run in a local network. Of course, I can use a trial and error approach and ping all machines in my network. Is there something better, something like a broadcast asking for the server, and the server responding appropriately? Is Qt providing something for this?
I'm writing client-server application and I need my server to find all clients in some network. I've already found some info here: Discovering clients on a wifi network, but I still don't understand how to implement this. Maybe somebody can say where I can find some code examples.
Thanks in advance.
PS. Working on c++, windows.
Generally TCP/IP is used as a communication protocol between client and server. For Windows platform Winsock library is used to implement TCP/IP. The server binds and listens on a port for incoming connections. Just like a webserver like stackoverflow listens by default on port 80 and then client (browsers) connects to it.
Here is a link to start. Here is sample
Normally all the client connects to server which listens on a well defined port. The server is only one hence the IP address and port is well know to all the client and hence they can connect to it.
In you case you want your server to have ablity to discover all the clients in the network. To achieve this the server needs to broadcast to network some message. The client will receive this message and will respond to the server that they are available on such IP and they can connect to server or provide additional information to server. Normally instead of broadcast, multicast is used which is limited broadcast. All the clients and server will subscribe to the multicast group which is a special kind of IP address. When server send a message to this multicast address all the client, which are subscribers of this address will receive this message and can respond back. Here is a sample
Edit: you can also use boost lib to implement multicast: sender eg., receiver eg.
I've got a problem in socket programming. I'm currently writing a simple server/client application which asks connecting clients to answer a survey (I'm following the exercises in the book: TCP/IP Sockets in C: Practical guide for Programmers). It works fine in my local network (using localhost to connect), but I can't make it work over the internet.
Since I changed some of the code found in the book, I tried to compile the original source code from the book but it still doesn't work. I assume this is not a code problem but a network problem.
I did some research and so I turned off my firewall, I forwarded the port I'm using (12543) in my router but it still doesn't work... I've got a remote windows server running Windows 7 for testing: when I run my server on it and try to connect from my computer it fails, when I try to run my server from my computer and try to connect from the remote windows server: it fails again. Even when I run my server on my computer and try to connect with the client from the same computer using my private IPv4 address 192.168.x.x or my public one, it fails ! Oh, and there is no firewall running on the windows server.
I really don't know what to do now... I can ping my windows server from my computer, I can ping my computer from my windows server, but it's impossible to connect to my application.
The source code can be found here: http://cs.ecs.baylor.edu/~donahoo/practical/CSockets2/textcode.html (SurveyServer2.cpp, SurveyClient2.cpp, SurveyCommon.h), but I don't think it's a code problem.
Please tell me if it's not clear enough. And excuse me if I did some grammatical errors, I'm french!
Any help would be appreciated, thanks!
EDIT : Ok, I know what's going on: it's a compatibility issue between IPv4 and IPv6! It's not properly working yet, but I now know what to fix. Thanks everybody :)
SECOND EDIT : Well, I think I finally understood. I was binding my server to a IPv6 address, but the host my server is running on only have a public IPv4 address. When I tried to connect, the DNS resolution only returned a IPv4 address so I was unable to connect to my server. I told to getaddrinfo to return only IPv4 addresses, so now it binds on a IPv4 address and it works fine.
There is surely a way to add a IPv6 address to my host but I don't think I will need it, it works okay right now, I hope this doesn't cause any trouble.
The code makes usage of getaddrinfo and need a hostname not a IP address.
It does sound like you have a connectivity issue or a DNS issue.
Ensure the name resolution is working:
Enter 'ping server_NAME' on the command line of the client machine.
If it can't find an IP address for the server name that could be your issue.
Ensure connectivity:
On the server command line:
enter 'netstat -an -p TCP'. This will show a list of all programs listening and their port numbers. You should see your server listening on port 12543.
On the machine where you are running your client program:
Use telnet to see if you can get through to the server. You can set the port number telnet uses with a command line option. Usually something like 'telnet -p 12543 server-ip'. If it says 'connection refused' then there's a connectivity issue (a firewall/etc). If it opens a connection you will get no error message and you will be able to type text to be sent to the server. You really only care if telnet was able to establish a tcp connection here.
If Telnet does connect then your issue is communication between the programs and not a network issue.
TCP standard has "simultaneous open" feature.
The implication of the feature, client trying to connect to local port, when the port is from ephemeral range, can occasionally connect to itself (see here).
So client think it's connected to server, while it actually connected to itself. From other side, server can not open its server port, since it's occupied/stolen by client.
I'm using RHEL 5.3 and my clients constantly tries to connect to local server.
Eventually client connects to itself.
I want to prevent the situation. I see two possible solutions to the problem:
Don't use ephemeral ports for server ports.
Agree ephemeral port range and configure it on your machines (see ephemeral range)
Check connect() as somebody propose here.
What do you thinks?
How do you handle the issue?
P.S. 1
Except of the solution, which I obviously looking for,
I'd like you to share your real life experience with the problem.
When I found the cause of the problem, I was "astonished" on my work place people are not familiar with it. Polling server by connecting it periodically is IMHO common practice,
so how it's that the problem is not commonly known.
When I stumbled into this I was flabbergasted. I could figure out that the outgoing
port number accidentally matches the incoming port number, but not why the TCP
handshake (SYN SYN-ACK ACK) would succeed (ask yourself: who is sending the ACK if
there is nobody doing a listen() and accept()???)
Both Linux and FreeBSD show this behavior.
Anyway, one solution is to stay out of the high range of port numbers for servers.
I noticed that Darwin side-steps this issue by not allowing the outgoing port
to be the same as the destination port. They must have been bitten by this as well...
An easy way to show this effect is as follows:
while true
do
telnet 127.0.0.1 50000
done
And wait for a minute or so and you will be chatting with yourself...
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Trying 127.0.0.1...
telnet: Unable to connect to remote host: Connection refused
Trying 127.0.0.1...
Connected to 127.0.0.1.
Escape character is '^]'.
hello?
hello?
Anyway, it makes good job interview material.
Bind the client socket to port 0 (system assigns), check the system assigned port, if it matches the local server port you already know the server is down and and can skip connect().
For server you need to bind() socket to port. Once addr:port pair had socket bound, it will no longer be used for implicit binding in connect().
No problem, no trouble.
Note that this solution is theoretical and I have not tested it on my own. I've not experienced it before (or did not realize) and hopefully I won't experience it anymore.
I'm assuming that you cannot edit neither the client source code nor the server source. Additionally I'm assuming the real problem is the server which cannot start.
Launch the server with a starter application. If the target port that the server will bind is being used by any process, create an RST (reset packet) by using raw sockets.
The post below briefly describes what an RST packet is (taken from http://forum.soft32.com/linux/killing-socket-connection-cmdline-ftopict473059.html)
You have to look at a "raw socket" packet generator.
And you have to be superuser.
You probably need a network sniffer as well.
http://en.wikipedia.org/wiki/Raw_socket
http://kerneltrap.org/node/3072 - TCP RST attacks
http://search.cpan.org/dist/Net-RawIP/lib/Net/RawIP.pm - a Perl module
http://mixter.void.ru/rawip.html - raw IP in C
In the C version, you want a TH_RST packet.
RST is designed to handle the following case.
A and B establish a connection.
B reboots, and forgets about this.
A sends a packet to B to port X from port Y.
B sends a RST packet back, saying "what are you talking about? I don't
have a connection with you. Please close this connection down."
So you have to know/fake the IP address of B, and know both ports X
and Y. One of the ports will be the well known port number. The other
you have to find out. I thnk you also need to know the sequence
number.
Typically people do this with a sniffer. You could use a switch with a
packet mirroring function, or run a sniffer on either host A or B.
As a note, Comcast did this to disable P2P traffic.
http://www.eff.org/wp/packet-forgery-isps-report-comcast-affair
In our case we don't need to use a sniffer since we know the information below:
So you have to know/fake the IP address of B, and know both ports X
and Y
X = Y and B's IP address is localhost
Tutorial on http://mixter.void.ru/rawip.html describes how to use Raw Sockets.
NOTE that any other process on the system might also steal our target port from ephemeral pool. (e.g. Mozilla Firefox) This solution will not work on this type of connections since X != Y B's IP address is not localhost but something like 192.168.1.43 on eth0. In this case you might use netstat to retrieve X, Y and B's IP address and then create a RST packet accordingly.
Hmm, that is an odd problem. If you have a client / server on the same machine and it will always be on the same machine perhaps shared memory or a Unix domain socket or some other form of IPC is a better choice.
Other options would be to run the server on a fixed port and the client on a fixed source port. Say, the server runs on 5000 and the client runs on 5001. You do have the issue of binding to either of these if something else is bound to them.
You could run the server on an even port number and force the client to an odd port number. Pick a random number in the ephemeral range, OR it with 1, and then call bind() with that. If bind() fails with EADDRINUSE then pick a different odd port number and try again.
This option isn't actually implemented in most TCPs. Do you have an actual problem?
That's an interesting issue! If you're mostly concerned that your server is running, you could always implement a heartbeat mechanism in the server itself to report status to another process. Or you could write a script to check and see if your server process is running.
If you're concerned more about the actual connection to the server being available, I'd suggest moving your client to a different machine. This way you can verify that your server at least has some network connectivity.
In my opinion, this is a bug in the TCP spec; listening sockets shouldn't be able to send unsolicited SYNs, and receiving a SYN (rather than a SYN+ACK) after you've sent one should be illegal and result in a reset, which would quickly let the client close the unluckily-chosen local port. But nobody asked for my opinion ;)
As you say, the obvious answer is not to listen in the ephemeral port range. Another solution, if you know you'll be connecting to a local machine, is to design your protocol so that the server sends the first message, and have a short timeout on the client side for receiving that message.
The actual problem you are having seems to be that while the server is down, something else can use the ephemeral port you expect for your server as the source port for an outgoing connection. The detail of how that happens is separate to the actual problem, and it can happen in ways other than the way you describe.
The solution to that problem is to set SO_REUSEADDR on the socket. That will let you create a server on a port that has a current outgoing connection.
If you really care about that port number, you can use operating specific methods to stop it being allocated as an ephemeral port.