I have implemented a simple client/server app using sockets, but now i would like to do so i have a ClientA that writes to server, and the server redirects the message to ClientB.
ClientA -> Server -> ClientB
I know how to implement ClientA and ClientB, but im having problems to distinguish ClientA from ClientB inside the server...
Server: I know how to read and resend the messages, i just need the logic to distinguish the clients.
If I understand the question, you have a server to which clients connect.
A server can have one of two roles, either the "sender" or "receiver". When a sender and a receiver connect to the server, the sender transmits data which is then passed on to the receiver. This is generically known as a "proxy".
One way to do this is to have the server listen on two different ports, say 3000 and 4000. Clients connecting to port 3000 (for instance) want to assume the role of sender, while those connecting on 4000 want to receive. If you have multiple senders and multiple receivers, then the clients will need to identify themselves to the server and indicate to which receiver they want to send or receive from (by sending login parameters, for instance), prior to setting up the data transfer connections. The details of how this is accomplished (data packets sent) is known as the "protocol", and you are responsible for designing it.
If clients can take on both roles simultaneously (sender and receiver) then you would have a single listening port on the server for all clients. The clients would then have to communicate to the server (by sending data packets) what connection they want to establish. Again, the details of how this happens are totally up to you. You must define the protocol.
Here's a sequence diagram of one (of many) ways to do this:
Client A Server Client B
|----login------>| |
| |<------login-----|
| |-------accept--->|
|<---acccept-----| |
|----data------->| |
| |-------data----->|
. . .
. . .
. . .
Client A login data message says "I am client A, I wish to send data to B"
Client B login data message says "I am client B, I wish to receive from A"
Server sends "accept" messages to both. When A receives the accept message it begins sending data and the server forwards it to B.
Issues to be dealt with include ordering of connections (what if B connects before A), connection failure (how does the server notify one client that the other disappeared), etc. These are all part of defining the protocol.
Related
I did a simple chatserver in the java ... I'm wondering about adding a username to a chat that you need to enter when you enter chat. Also, I do not understand how private messages are sent only to the addressee
If the destination is not logged in to the chat server, the error message should be sent to the sender
Each message sent by the server to the client must be accompanied by the name of the original sender and the time when the message was sent.
Java Code ---> https://dijaspora24.info/?page_id=4123
I am not going to show the implementation, since it's a big problem to solve here. However, I will give an idea of how to implement this.
I assume you know how to connect a client to a server (for example by using ServerSocket and Socket).
First, to add the username of a connected client, the server simply has to force the client enter a string to the server as the first thing when it connects to the server.
Second, create a Map to store all clients, where key is the username entered and value is the socket.
Third, when a client want to send a message to another client, some format must be used to send a string that is understandable by the server. When sending a string to another client, the username of the receiving client must be within the string. When the server receives the string, it extracts the username of the receiving client's username and locates the client in the Map by its key. As mentioned, the value of the Map element is the socket instance of the client you want to send to.
To make all of this possible, a thread must be used for each client that listens for input from each client.
I have a distributed system application that uses JBoss as an application server. I have a client application that serves as a simulation engine. When client is up, it sends an registration message(JMS message) to Server, then some field is set in the database. When Server is up, it sends a message ( a topic) to all clients to check that they are alive. If clients are alive, they can read message and send a response to server (queue) that it is alive.
If user close client normally, client send a message to server that I will unregister. Then server unregisters it. This is done in database side.
If user close client abnormally(kill) , then client can not send a message to server for unregistration. Then server does not know this client is not alive anymore. This causes inconsistency in my application. So I need a way to understand that client subscribed a topic is not subscribed anymore.
Server sends a message to topic to check that clients are alive.
#Schedule(hour = "*", minute = "*", second = "30", persistent = false)
public void sendNodeStatusRequest() {
Message msg = MessageFactory.createStatusRequestMessage();
publishNodeMessage(msg);
}
After a time, Server show following logs. Could I catch this warning from Java?
07:17:00,698 WARN [org.hornetq.core.protocol.core.impl.RemotingConnectionImpl] Connection failure
has been detected: Did not receive ping from /127.0.0.1:61888. It is likely
the client has exited or crashed without closing its connection, or the
network between the server and client has failed. The connection will now be closed. [code=3]
07:17:00,698 WARN [org.hornetq.core.server.impl.ServerSessionImpl] Client
connection failed, clearing up resources for session 4e4e9dc6-153e-11e7-
80fa-742b62812c29
To me the whole point of messaging system is decoupled communication. The sender (server in your case) send its stuff to the topic without actually knowing who will get the message. The clients come and go, and they should be able to read the message whenever it (still) resides in the topic.
Now from your question I understand that the server keeps track of all the connected clients by means of receiving the message back to the dedicated queue.
So I'm asking myself - maybe its something wrong with the design here.
Let me propose slightly different way of implementation.
The server should not be aware of any client, at most (because your system seems to work this way) it should know that client A, B and C are alive now only because these clients passed to the server this knowledge.
Why just don't make clients sending the "keep-alive" message every, say 1 minute (or less, depending on your needs) to the server queue without prior message from the server.
The message can include some client identifier and probably time if its not added by the infrastructure or something)
So the server will just get this message and it will keep track in memory the list of available clients along with the last time they've sent something.
So if some client disconnects "gracefully" - it can send a special message to the server like "I'm client A and consider me disconnected". Otherwise (abnormal termination/network outage/whatever) - it just won't send anything, the server will have a special process that will check whether there are stale clients on the list and if it finds them - it knows that something went wrong.
If you still want to stick with JMS way of doing, then you can try to send the message synchronously, meaning the producer will wait until it hears from the consumer. More information here : http://docs.oracle.com/javaee/6/tutorial/doc/bncfa.html
I'm using channel-adapters (not gateways) to send data with MessagingTemplate's sendAndReceive from spring integration server to a connected nonspring client (or just telnet).
After receiving the data in the client, somewhen I want to reply data to the server and resolve that sendAndReceive-Waiting. I still want to be able to send other data to the server.
How will sendAndReceive detect a response? Right now I can send whatever I want to the server, it will assume it as a new incoming message.
Is there a predefined way, like prefixing a messageid or do I have to implement it manually by interpreting the incoming messages and somehow "resolve" the sendAndReceive-blocker?
MessagingTemplate.sendAndReceive is based on the TemporaryReplyChannel which is placed to the MessageHeaders and afterward some AbstractReplyProducingMessageHandler just uses that header to send reply back.
Yes, the sending Thread is blocked to wait for the reply throughout that TemporaryReplyChannel.
Hope that can help you a bit.
All other your comment regarding TCP/IP isn't clear for me yet...
I'm trying to make a port of a chat program a friend of mine made with lacewing and multimedia fusion 2 for android device.
I've managed to create a socket connecting to the listening socket of the server successfully, but I cannot seem to be able to send data to login and enter the chat. The login for now just requires a name, but even if I send a String of data, the server doesn't seem to reply or accept that data to get me over the channel.
I know I could easily port this with other way like using the NDK of the multimedia fusion 2 exporter, but I just want to figure out how this works
PS: I'm using Java and libgdx for the development
You need to read the liblacewing relay protocol:
https://github.com/udp/lacewing/blob/0.2.x/relay/current_spec.txt
On initial connection, you have to send byte 0 to identify that you are not an HTTP client. After this, you can exchange normal protocol messages.
The first message you need to send is the connection request (which may be denied by the server with a deny message). This would be:
byte 0 (2.1.0 request)
(1.2 size)
byte 0 (2.1.0.0 connection request)
string "revision 3" (2.1.0.0 connection request -> version)
When the server responds with response 0 (2.2.0.0 Connect), you then have to set a name before you may join any channels. This is done with message 2.1.0.1 SetName, which is the same structure as above but instead of 2.1.0.0's byte 0, it is 2.1.0.1's byte 1, followed by the name as a string instead of the protocol version.
The server should then respond with 2.2.0.1 SetName, assuming it accepted your name change request. You should process this message in case the server gave you a different name than you requested. Finally, once you have a name, you can join a channel with 2.1.0.2 JoinChannel. The flags you specify here will be used if the channel doesn't exist yet (e.g. nobody is in the chat yet) - these should match the ones in the MMF2 project file. The name should also match.
After all that, you're still not done! You have to process more messages, etc. it's almost like writing the RelayClient class yourself. It's a tough task, but with the protocol specification in hand you should be able to work it all out.
I'm a learner, so please be patient and clear. I am writing an echo client with Java sockets (DatagramSocket).
After the client sends a message to the echo server, the server deliberately sends 1-10 copies of the message back to simulate message duplication in UDP.
However, my code can only receive the first of those messages sent back, never the full number sent by the server. My receive code is like this:
socket.receive(receivePacket);
How would I put my client in a state where you can enter a string to echo, say "Hi", it is then sent to the server, but can then receive all the replies? I am assuming that they all make it back to the client (I am testing this on my local machine so there will be no loss)
Call socket.receive again to receive additional packets. Set a timeout to wait a reasonable amount of time before deciding the server has sent all its packets.