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.
Related
I have implemented a simple P2P multicast network where each peer connected to the network sends data to every other peer. In order to make it possible, I made use of Java MulticastSocket Class, so every peer joins a multicast group defined by an available for multicast IP address, and a port number.
I got some issues while trying to run the program using EC2 services, where each generated instance represents a peer of the network, because the peers are not able to communicate in so far as exchanged messages do not reach the receivers.
Hence, basically my question is: is there a way to make EC2 instances communicate to each other using Java MulticastSocket? Can anyone help?
Natively, you can't.
Q. Does Amazon VPC support multicast or broadcast?
No.
https://aws.amazon.com/vpc/faqs/
Same thing for EC2 Classic (though there is hardly any reason you'd ever want to use that, if your account even allows it).
VPC looks like Ethernet, but it isn't. Put a packet sniffer on and try a ping. Watch the ARP traffic on both sides and you'll see something enlightening -- the source machine arps for the target and gets a response, but you'll see neither of these packets on the target machine. The ARP response comes from the network infrastructure itself.
There's a workhackaround, if you're feeling crafty: you can build an overlay mesh network that transports multicast over unicast.
See https://aws.amazon.com/articles/6234671078671125
So the problem is I have fifteen clients which need to be able to communicate between each other. My question is how should this be done? Clearly one way is to simply make the clients also servers, but that means 120 unique connections necessary to fully connect the fifteen clients. I'd rather not do this as it seems messy.
Current solution:
Each new connection has the server spin off a separate thread for listening to it. Each client has a separate thread monitoring the channel for incoming information.
Server acts as a message router: Process 1 needs to send a message to Process 2 and sends a message to the server indicating intended recipient, sender, and message.
Upon receiving the message the server passes message to Process 2. The listening thread detects it and passes it to the process.
So on for each message between the clients.
This seems clunky. Is there a better methodology/package to use for this?
A UDP multicast system would work for this but will get complicated for you to do yourself (since you have to worry about synchronization and fault detection/correction yourself as well as nodes droping in and out of the group).
There are various middleware solutions including distributed caches that already address this problem pretty well. Look at Infinispan. If that's too high level and you just want a lower level solution, try JGroups. I only list those because I know they are quick and usable, but there are many others out there.
I am facing a problem regarding designing my app with datagram socket. My app needs to communicate with different servers using udp connections. now I am not sure which of the following will be good. Is there any advantage of any of the following ( by performance or by other measures ). or is there any better option?
Option 1
create a single Datagram socket, and create a single thread to receive data of that. While sending to different servers set the address of the datagram packets. and in the receiving thread check the address and process data accordingly
Option 2
create different datagram sockets to communicate with servers. use socket.connet() to connect to the relevant server. And create threads for every socket to receive data.
N.B. I am actually working on an android app. if you have any query you can ask in comment
Unless you are we are talking about 100000 of connections, I would create single socket per thread. It speeds up application and guarantee the thread safety of sockets and that receaved data wont get mixed up.
The most important is however, that if one channel will fail or latency will get high, it will have no influence on other channels (sockets).
The drawback is that you are consuming more resources.
All depends on purpose of app.
My opinion is you can create a single socket to because creating more socket will bring down your app.
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.
I'm making a java program & I want this to be both as server and a client (using sockets). How is this best achieved?
If you mean that you want to both send and receive data, a single regular socket (on each computer) will do just fine. See Socket.getInputStream and Socket.getOutputStream.
The usual "server" / "client" distinction just boils down which host is listening for incoming connections, and which hosts connect to those hosts. Once the connection is setup, you can both send and receive from both ends.
If you want both hosts to listen for incoming connections, then just set up a ServerSocket and call accept on both hosts.
Related links:
Official trail: The Java™ Tutorials, Lesson: All About Sockets
If you want each station to function as a server and a client, like a p2p chat,
you should implement a thread with a ServerSocket, listening for incoming connections, and once it got a connection, open a new thread to handle it so the current one will keep on listening for new connections.
For it to be able to connect to others, simple use SocketAddress and Socket, in a different thread to try to connect to a specified server address (e.g. by a list of the user's friends)
you can find plenty of chat examples by googling.
cheers.
If you want the program to perform the same operations regardless of whether it is a server or a client for a certain connection, I could imagine handing off both the client Socket and the ServerSocket.accept()-produced socket to the same method for processing.
Have a look at jgroups it's a library that allows the creation of groups of processes whose members can send messages to each other. Another option would be to use hazelcast...
You may also look at this question.
The best way to do this is to run the server on a thread:
You run server.accept() therefore while your program is listening for a connection on that thread you can do whatever you want on the main thread, even connect to another server therefore making the program both a server & a client.