I am having problems trying to get UDP to work with SFML in C++.
I have made a client class and a server class.
The server can send text messages and the client can receive and print them.
Server and client runs in the seperate threads.
The problem is, it is not working on LAN.
If I have the client and server running in seperate windows on the same computer I can send messages just fine, but if the server runs on one computer and the client on another on the same LAN, the messages aren't received.
I hope someone can help.
Thank you in advance.
Related
Writing a UDP client-server app in C++ (done that lots of times before in many languages in the past 15 years), but somehow this one is not working correctly.
I cannot post actual code nor minimal reproducible app at the moment but I am willing to pay for live help if anyone is available to help solve this quickly with screensharing.
I think this is a particularity with C++ sockets and the way I am using them in this specific app which is quite complex.
Basically the issue is that the packets sent from the server to the client are not received by the client, only when said client is on a separate nat.
When both in same local networking and using their local IP, everything works as expected.
Here is what I am doing :
Client sendto(...) packets through UDP to the server using a specific server host and port 12345 (and keeps sending these non-stop)
On another thread, client bind(...) on port 12345 and "0.0.0.0" and tries to poll() and recvfrom() in a loop (poll always returns 0 here when client is on a separate nat)
Server bind() on port 12345 and "0.0.0.0" then poll() and recvfrom() in a loop
Upon receiving the first UDP message from a client, it starts a thread for sending
UDP messages back to the client on a new socket, using the
sockaddr_in that it got from the recvfrom() to pass in the sendto() commands.
Result : Server perfectly receives ALL messages from all clients, and sends all messages back to all clients, but any client that is not on the same NAT will never receive any messages (poll() always returns 0).
As far as I understand it, when the client sends a UDP message to the server on a specific remote port (12345 in this case), it will punch a hole in its NAT so that it can receive messages back from the remote server on that port...
I tested five different client network configurations :
Local network with the server, using local IP addresses (WORKS)
Local network with the server while client is using a VPN thus going through a remote NAT (DOES NOT WORK)
Local network with the server but client is using the WAN ip address to connect to the server (DOES NOT WORK)
Client at an actual remote network from a friend's connection, behind a router (DOES NOT WORK)
Client going through a wifi hotspot created using my phone (DOES NOT WORK)
For all tests above, the server was correctly receiving all communications from clients.
I also tried forcing the port to 12345 for the sendto() instead of using the sockaddr_in as set from recvfrom(), same issue.
Am I doing anything wrong ?
If you want to help but need to see actual code, I can do that live with screen sharing and I will pay for the help.
Thanks.
Also, if anyone can point me to a great site where I can pay for VERY QUICK help, please let me know, I don't even bother searching google because I really want actual advice from people who tried these services, not ads trying to rip me off...
Only the original receiver socket is allowed to reply to the client, because it's the client request that opens the port in the NAT. So either use the same socket in the server to receive and reply, or get the port that the second server socket was bound to and transfer it with an initial message through the original server port, so that A can send to it and punch the hole.
It looks so strange to create two half duplex sockets when a socket is a full duplex communication object that I'd go with the first option.
I've got server running in background and a program which should display data from server. I want to somehow launch method in my program from server. So server should be a sender, but how to do it ?
There is no reason why a server can't also be a client, just implement the interfaces from both sides and you're good.
The main thing to worry about is deadlocking: if you have a single threaded program which is waiting for the reply of the server, then it will not handle the request that the server sends, so the server is stuck and will not send a reply to the program.
This can be solved by starting the server implementations on different threads and letting them not block on the client thread.
Even better is to avoid having a server send back requests before sending replies, but cascading requests (forward requests to more specialized servers) should be no problem.
I have one main PC and 3 other client PC that I am trying to send message to. All of them are in the same network, and I like to send a message to them, one by one, so that they do something simple like printing and sending a success msg to the main computer (server). I am new to MPI, so I don't know how to make this connections? How does the client computers listen to the msg from the server? I have written a program that separates the functions of clients and server. If it is the client it would connect to that with the specified port number and ip address and send a msg to the client. However when I try to do MPI_Open_port(info, port1); it gives me an error that if fails to open the port. Should I have this program on all client computers? If someone can give a general overview of how it works I would appreciate it.
sorry for the noobish question but I can't find any resources online clearly stating whether this should work or not, and all tutorials / sample code always use localhost ^^ Soooo...
I'm trying to setup a simple server / client using RakNet. I'm literally just following the first tutorial (http://www.jenkinssoftware.com/raknet/manual/tutorial.html), just trying to get the client to connect to the server and keep the connection alive for a bit.
It all works great as long as I use 127.0.0.1 or 192.168.0.XXX, I can start the server, then the client, the server detects the connection request and sends the reply to the client, the client receives the reply and prints out "connection accepted" and such, and I can exchange messages between the client and the server.
However if I try using my actual IP, the server does not seem to detect the connection request (if you look at the tutorial code, it doesn't print "incoming connection"), but the client still receives a reply from somewhere ("Our connection request has been accepted").
After this initial semi-successful connection, no more packets will be received by either server or client, and the client will inevitably get disconnected after a few seconds (I assume time out?).
Port is open on the router, and the app runs fine as long as I keep it on localhost.
So my question is: is it even possible to run a server and client on the same machine / IP which is sitting behind a router?
The RakNet documentation part about NAT punchthrough and UDP forwarding does mention no more than one client and server being able to run on the same machine, but I was under the impression that one server / one client would not be an issue?
Thanks in advance to anybody who can shed some light on this!!
Forgot to mention my firewall is disabled !
I am pretty new to socket programming - so this might be a simple question but I'd really like to clarify.
I have a multiple-client to single server program: the individual clients send messages to the server which processes them, and then passes it on the destination i.e. the server is an intermediary.
On the server side, there is one thread for each client which is meant to 'listen' for messages from the clients (which will be placed in a buffer). At the moment all the clients are sending messages to the same port (as far as I can tell).
I am thinking of setting up another thread on which the server will process the messages before transmitting them on. Does it make sense to use another port on the server to send those messages?
I don't mean this to be a discussion, but I don't know what is common or more logical to do - any advice?
On the client-side, I am planning for it to have one thread for sending messages to the server, and another thread for receiving. Please let me know if any other information is required!
edit
At the moment it is a 1-server-to-multiple(tens now, hundreds later)-client program - I seem to have problems with the client receiving messages from my server (I am troubleshooting so I thought that using the same ports might be the problem), but I will try it with the same ports again and see. I thought it might be a matter of the receiving port being too busy to send messages as well.
At the moment all the clients are sending messages to the same port (as far as I can tell).
What do you mean 'as far as I can tell'? You must know whether you are opening more than one port at the server.
Does it make sense to use another port on the server to send those messages?
No it doesn't. If you're using TCP, send the messages back down the same socket. If you're using UDP you don't need more than one UDP socket, and it simplifies the client and the application protocol if replies come from the same ip:port the request was sent from.