I am learning about UDP client server where the communication is one way from Server to Client. Server will send UDP packets to Client.
I want to to make it dual communication where Server and Client can send UDP packets to each other.
Do I need to make another Datagram socket for Client Server to make it dual communication or can I use my existing Datagram socket to do the job. If I dont need another Datagram Socket , I would appreciate if you can show me how it is done
I would appreciate if you can point me to relevant resources on dual commuication for Client Server
Yes, you can use the existing DatagramSocket.
Take a look at example in this link:
http://phoenix.goucher.edu/~kelliher/s2011/cs325/feb25.html
Its upon you how to use the send and receive methods of a socket depending on your needs.
Related
In socket programming using java , we need to specify in the client side the port number in which it will communicate through it with the server using the socket class . On the other hand , in the server side , we don't need to specify the client port number through which we will send our responses to the client , we just create a port number through which we will listen to the request and we just wait for this request to arrive using the accept () method. So please someone explains how the responses are sent from server to clients although we don't specify the client port number ?
Both TCP port numbers are in every TCP segment. When the incoming TCP connection is accepted at the server, the server (specifically the TCP protocol implementation in the server) knows all it needs to know to respond to the client.
I am new to socket programming and I need to clarify some things.
Do you need a server between two client communication? Let me explain what I mean:
Example 1:
Client1: Server, I want to talk with a client2
Server: No problem. Let's just wait until he sends the request to connect
Client2: I'm here. I want to talk with client1.
Server: Okay Client1 here is Client2 IP address. And for you Client2, here is
Client1 IP Address. You can now talk to each other without me.
Example 2:
Client1: Server, please send client2 a message: "Hey client2. How are you?"
Server: Okay no problem. Sending message to client2
Client2: Server thanks for sending client1's message. Send him a reply: "Hey, I'm fine."
Server: Sending message to client1..
So my question is: Do you need a server after you met two clients together to communicate between them? Or I'm on completely wrong track?
EDIT:
The purpose behind this is that I want to expand my very simple mobile game to become a multiplayer. Just for example, I want to show PACMAN2 on PACMAN1 mobile phone and vice versa.
If you are using a TCP socket programming, you need central server to facilitate communication between clients.
Reason - You cannot connect to a port on one client from every other client. All clients can connect to one server on a particular port and server can facilitate the communication among clients.
If you move away from socket programming and use advanced features like Messaging; peer to peer communication and broadcasting of messages to multiple clients can be achieved.
EDIT:
Still I prefer TCP over UDP for these reasons especially Reliability
In your case of multi player games, still your clients need to be connected to server on dedicated socket. Since you have to use TCP anyway, server can take care of sending messages between clients with client id.
yes, you can do with peer to peer communication does not need any central server or you can also use sockect or you can communicate with user ip address.
Ref
peer to peer
Having the two client applications could theoretically communicate directly and this could work in a LAN but in practice it is unlikely. The main reason this won't work is that in many cases the IP address of client 1/client 2 that the server "sees" is actually the IP address of the network gateway for client 1/client 2 which means that client 1 cannot initiate a connection to client 2. Also you can have the firewall on client 2 machine (or its network) blocking the connection initiated from client 1.
You might find useful information if you read more on XMPP.
To put what Kevin Kal said into a answer:
no you do not necessarily need a server for Client1 and Client2 to talk to each other. If you use the server in your example to send the necessary data (IP and port) to Client1, Client1 can connect to Client2 via a socket Client2 listens to (and as Kevin said, this makes Client2 into a server, strictly speaking.)
If you want to know more about Client to Client connections in java here's a really good answer to a similar question:
Connect two client sockets
I'm developing a chat application in Java that enables client to connect to a predefined port and when two clients are connected the server should connect those two sockets and data should be exchanged between them.
I know to create a ServerSocket and Socket that will connect and establish a communication between them through a separate port and a server socket. But, how can I connect those two connected clients?
If you are creating a chat application then Chat server will not connect client socket in order to communicate.
You can try following approach:
On server side Use a HashTable to store connected clients.
When you receive a message from client, include a an id of CLient to whom message is to be sent and simply pass on the message to other client.
There will be separate threads running for these clients, so you need to have a policy to control the load on server.
This questions sounds like a homework assignment.
If you would like to see a great contemporary demo of a chat system you may learn from Play's WebSocket chat sample application.
I am trying to write a piece of software that
accept simple UDP messages (text strings) from simple UDP client,
opens connection to another server and forwards messages to it
listens for that server reply and
forwards that reply back to the client.
So it is a simple intermediate server.
To visualise the communication:
Client <---> Intermediate Server <---> "Real" Server
The client connects to the Intermediate but has no idea that the message it sends is being forwarded to another server, or that it's reply is actually from another server. As far as the client cares it the Intermediate server is the real server.
I am trying to use Java's DatagramChannel for this, but not quite sure how to correctly do this in a non-hack way. Do I use two DatagramChannels? One for Client--Intermediate and the other for Intermediate--Real Server?
An general outline of approach would be appreciated, particularly if I need to open a socket every time I need to forward a message from the Intermediate to the Real Server, or if I can keep that socket open somehow.
You only need one datagram socket for this, and you can keep it open for the life of the process.
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.