Let's say I want to send a message from one client to another. How should I approach this problem? Obviously I will have to send this message to server, but what's next? I have few ideas, but every idea seems to be wrong.
thanks
Client1 - send message for client2 to server
Client2 - check any period of time for the messages
OR
Client2 - Open Websocket to the server.
Client1 - send message for client2 to server
Server - push message to client2
direct client-to-client communication my be very difficult due to client firewalls.
Look at the tutorial for sockets in java
http://docs.oracle.com/javase/tutorial/networking/sockets/
Also you don't necessarily need a server. You can have the clients have both an incoming and outgoing channel and do it that way.
So
Client1 sends on its outgoing to Client2's incoming
Client2 hears on its incoming and responds on its outgoing to Client1's incoming
Client1 hears on its incoming
You can use the standard Java JMS approach to send asynchronous messages between applications. Read more at : http://java.sun.com/developer/technicalArticles/Ecommerce/jms/
If by web application you mean HTTP based, than you must know HTTP is a request based protocol. In other words, the server only responds to HTTP requests that come from the clients (browsers, most of the time), so after a client sends a message, all the other clients that want to receive that message must ask for it, i.e. make a request to the server. Typically, this is achieved using an auto-refreshed HTML page.
Related
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
So I have a server with a few clients.
When a client sends in a message I'd like the server to send it out to any one of the clients. However I don't really want the clients to be polling for messages, rather, I'd somehow like the server to check if they are online and then send them the message if they are.
I'm assuming the client will need a socket that's listening for incoming messages?
But what's a good method for the server to 'test' if the client is online? How the server know the address of the client?
I'm using Java with JAX-WS.
I'm sure there must be some method or design pattern for this that I'm not finding via google?
I am doing a project of Restaurant ordering system in that I gave order by using different client and process that order and that order can send different system, e.g:
kitchen1
Kitechn2, and
kitchen3
First I can create different client by using rmi threading concept an and they can send (means all client) data to my server i want to sent that data into different client
How can I do that? I do create different client and send data to the server suggest how can I do that?
RMI is a synchronous (request/response) protocol - the client sends a request to the server, which it can respond to.
The server cannot arbitrarily send more data to the client.
The simplest way to asynchronous communication in Java via JMS using a message broker like Active MQ.
The process would go something like this:
the server starts and connects to its incoming request queue.
client 1 creates a temporary queue and registers with the server via the request queue passing the name of its temporary queue.
the server stores the client and the name of its termporary queue.
client 2 does the same and server stores the client and the name of its termporary queue.
client 1 sends a message to the server causing the server to send a message to client 2, which is does via the temporary queue that client 2 registered with the server.
client 2 reponds to the server causing the server to send a message to client 1, which is does via the temporary queue that client 1 registered with the server.
This can go on until one or both client shuts down, at which point their temporary queue are closed and the server can no longer send messages to that client (though it's best the client de-registers itself).
I have a TCP/IP socket server which send multiple response to client based on client's requirement ( like send update whenever DB has an update). client sends xml and server too respond xml.
I stumbled on Netty yesterday. I want to know whether Netty can support my multiple response server application?
Sure as long as the protocol which is used can handle this kind of message flow.
I have a client socket which sends messages to the server.I want to get an acknowledgement on the client side whenever the server receives the message. Is it possible to get that acknowledgement. I developed the client using apache mina. Thanks in advance.
There are no messages in TCP, only a byte stream. There is an internal ACK mechanism that tracks how much of the stream has been correctly received, but it is not available to applications. If you want an acknowledgment from the server, your server will have to send it.