I am writing this game in Java and have problems with networking architecture.
I decided I will UDP packets. I am just at the beginning, but the problem I am facing is that it seems to be that server have to respond from exactly same IP/Port to client (which is behind router which uses NAT) as client connected that server.
For example I have client A behind router. Client A has IP (local) 192.168.8.100 and it connects server B from port 1234. Server is on 11.11.11.11:2345.
When client A connects to server B it uses 192.168.8.100:1234 but router converts that to (for example) 22.22.22.22:6789.
Now, when server wants to send packets to that client it has to be from 11.11.11.11:2345.
I would like to send data from another port like 11.11.11.11:2222, but this does not seem to work, at least not with my router.
I want to use different port because I want to have two threads one for listening and one for sending data, and each thread would have it's own DatagramSocket. But, as i said once client A connects to server on port 2345, I can not send data from port 2222.
Does anyone know how is this handled? I am doing it in Java, but it's not really a language specific problem.
UPDATE
After #Perception commented I have some more questions regarding his comments:
OK, so if I understand this correctly, if I have server which is hosting 1000 games, each with 2 players, all sending/receiving will have to be done through the same DatagramSocket.
As I understand DatagramSocket is thread safe so I guess I can have one thread doing:
datagramSocket.receive();
while at the same time second thread is doing
datagramSocket.send(.....);
Correct?
Also, two threads can send data at the same time through the same DatagramSocket? Is sending in any way serialized, meaning that second send() starts only after previous send() is finished or is data being sent at the same time?
gorann, I'm not sure if I'm understanding you correctly, but it sounds like you're trying to control the port on which the server communicates with the client. There's no way to control this, and for good reasons.
This is one of the trickier differences between TCP and UDP.
When a new TCP session is initiated, the server side call to accept() gives you a new socket and the OS handles multiplexing the various sessions for you. With UDP, you need to handle the multiplexing yourself. But you need to do so in a way that works with NATs and other firewalls.
The way NAT works is that when it sees an outgoing packet, it creates a temporary rule allow packets to return along the same port pair. Data returning from a port that the client has not yet sent to will likely be blocked.
This gives you two choices:
You could do all of your communication through a single port. This is not a bad option, it just means that you need a way to identify client sessions and route them to the appropriate thread.
You could create a separate port and instruct the client to send to that one instead. Have the server listen on a fixed port. The client sends a message to there, the server then sets up a new session port and sends that number back to the client using the server's listen port. The client then sends a message to the session port, which causes the NAT to open up that port and allow return traffic. Now the client and server thread have their own private port pair.
Option 1 is a bit more work because it requires data to be exchanged between threads, but it scales up better. Option 1 is easier and more CPU efficient because each session thread can be independent, but there are a finite number of ports available.
Either way, I recommend that you have the client include a semi-unique session id in each packet so that the server has more than just the client address and port number to verify who belongs to each session.
Related
I want to create a three way communication system in which every party has equal rights, with two communication channels to his partners.
The program is decentralized and every machine runs the same code, in which there is a list of three IP addresses, with every one representing one of the machines. For each machine the partners' IP addresses are determined by looking at it's own IP address and using the other two from the list.
Now there is no predetermined order in which the machines are being turned on, is there any way to control the TCP communication other than setting it something like
'if the IP address you want to speak to is higher than your own, connect to a server, otherwise you are the server and accept sockets'?
In the end I want a TCPread(port) which fires every time a message from any IP comes in and a TCPwrite(port, ip, message) which sents a message.
My idea was a TCPhandler which stores all sockets it's got for every port I plan on using in the programm with one thread per port. Then everytime a read or write is performed it checks if there is a socket for the port and IP address in the handler, if not it sends a socket to the IP and waits for a response... I don't think i've understood that whole TCP thing entirely though.
If you don't care about number of connections you can do following:
Each peer open port and listen for incoming connections
Try to establish connections to each peer with some period of time
As result you will get two connection between each peer. Now you can use them following way:
Outgoing connections are used for sending messages
Incoming connections are used for receiving messages
I need to have a UDP server which allow me to receive/send informations from/to clients which dynamically will open a socket with a free port (so it will be differente from device and device). The client will send and receive in the same port, so the server must be able to communicate with it.
how could I set the server to stay open in every port? if I had 250 thousand users how could I handle them without tails problem and preventing the port to be occupied from another client?
I thought about open every port with different sockets in a different thread, but I don't know if this is a correct way.
A UDP Server can listen and be open on only one port. All clients can send data to that port. The server will have to handle each data and respond if needed to the peer who sent its data. This should happen even if more than one client wish to send data to server. In UDP context one client will not hog the server port.(Unless the application is badly written).
I am working with a Java desktop server and multiple Android clients connected to it. on the server side I need to identify which client has sent me a message by sockets TCP/IP and send a response only to that one client and not the others.
I will store all the sockets of clients in an ArrayList.
first here are two ways that I tried that don't work;
-- the IP address of the client, get this by calling socket.getLocalSocketAddress() in the client and socket.getRemoteSocketAddress() in the server, but they never match. for example i got in the client XXX.XXX.11.17 and in the server XXX.XXX.0.13, they are supposed to be the same for the same connection.
-- the port number, get this by calling getLocalPort() in the client and getPort() in the server, yes this works perfectly and the numbers match so I can use this, HOWEVER there is a possibility that the randomly selected port numbers on two different clients could be the same. not likely but possible. so that means there is no guarentee that they are unique.
what is the alternative that I can use that will work?
I need to identify which client has sent me a message by sockets TCP/IP and send a response only to that one client and not the others.
Send it back down the same socket you received the request from.
If you need a permanent identified for the client, you can use the result of Socket.getRemoteAddress().
getLocalSocketAddress() in the client and getRemoteSocketAddress() in the server [...] are supposed to be the same for the same connection.
No, because you don't know what's in between. Most mobile providers use proxies, NAT and so on. The mobile device thinks it's on a LAN (10.0.0.x or 192.168.x.x addresses) which the provider provides. It's even possible for multiple clients to have the same remote address (as seen from your server).
That being said, you can uniquely identify a client in your server application by the remote IP address and port combined together, given the server listens on one IP, port and protocol. This information is available from socket.getRemoteSocketAddress(), where the returned InetSocketAddress (in case of an internet socket) contains both the remote IP and port (getAddress() and getPort() respectively).
But as indicated by the other answer, you don't really need a way to identify a client. A network client is identified by the socket you receive data on (a socket is an exclusive connection between two nodes), so just send the data back to the socket that you received the request on.
If you do need more bookkeeping data about the connected client, wrap the client socket in a wrapper class that contains additional information.
I am trying to write an application which will run in many machines, and these machines will communicate with each other through sending a stream of UDP packets. Usually one machine will be sending many packets to another machine, until they switch and another one will do the same to another machine and so forth. Choosing UDP is due to the nature of the application (real-time/speed more important than reliability). I also understand that UDP is a connectionless protocol.
By doing a quick prototype, I managed to create a NIO Datagram Server (bind), and a NIO Datagram Client (connect). However, I realized that I can only send one way only from the client to the server (or maybe I am missing something?). I couldn't send in the opposite direction.
Also, since UDP is a connectionless protocol, I thought that it was supposed to accept many clients sending packets to it (n-client to one server), and the other way around (server sending to clients one-by-one or multi/broad-cast).
Should I create a server in the client listening to a different port to acheive two-way? Can n-client send packets to one server at the same time?
I just want someone to clear this thing to me. No need for sample code (although it will be greatly appreciated), you can give me some pointers.
Thank you.
For what you are describing, you need one server thread and one more client thread in EACH and EVERY instance of your program running on different machines.
Create a multi threaded program, with a serving thread, and a client thread - the client thread needs to know about all servers - IP and Port. The server simply listens on a port on the current machine.
If you run this same program on multiple machines, You will get a p2p group.
You can also set up a tracker on a free server in the internet. A tracker program will rest in a well known URL, and will maintain a list of participating machines. Each instance of your program when started on a machine will update the tracker of details necessary to connect to it, and the tracker can maintain a list of this data and share it all with any new instance coming up later.
Ok so I've found out Sockets are not serializable... so I cant pass them over TCP...
My problem is I have a homework assignment where I have 10 servers that must listen on one socket(lets call it request). For input from any of x number of clients that write to that socket. Then after one of the server processes reads a message from request it must communicate with that client over its own socket...
I tried making each server socket and the request socket on the server side, then passing those to the clients when they connected to the server... but this doesn't work...
Any tips on how I might do this? Having TCP not be 1-1 is really toying with me here.
Passing a socket over a TCP connection is like trying to pass a telephone over a telephone call, or trying to fax your fax machine. What you need to do is organize another connection between the parties concerned.
EDIT: In fact your assignment as stated doesn't even make sense:
I have 10 servers that must listen on one socket(lets call it
request).
That's not even correct terminology. Servers listen at ports, not sockets, and 10 servers listening at one port is impossible. They must each have their own port.
For input from any of x number of clients that write to that socket.
See above. Clients don't write to 'that socket'. They create their own socket that is connected to the server port, and they write to that.
Then after one of the server processes reads a message from request it
must communicate with that client over its own socket
If the server has received a connection from a client it already has a socket representing its endpoint to that connection. So all the server has to do is write the response back to the same socket it read the request from.
In short you have a major terminology problem, but you don't have a software problem at all.
Passing sockets seems crazy to me. If you're trying to write a better server, you'll have a hard time beating Netty. I'd recommend giving it a look.