How I can send file from one client (A) to another one (B) via socket? and vice versa, send file from B to A. I mean that make the client sender and receiver at the same time.
In other word, when muticlient connect to server, how I distinguish between clients ?
You need to implement you own communication message format in short a simple protocol .
You keep a list of all active sockets in a shared list/map , and based on the request from the message you pick up the apt client and push the desired message to that.
You can implement the actual message format as you want, but this can be the blueprint.
In this case lets say your client A sends message : 1. Client Id 2. File Start 3 X . File Content 4. File End
as soon as you get a connection you get the target client id , the file start message lets you understand the next message just needs to be diverted to target and file End message defines the transfer complete.
Also, you may would like to send Acknowledgement message from server to client, in order to eradicate transfer issues.
It is good way to manage client using their id(i.e. a unique long or string or any other for each user). At the time of connection to socket client send their id , store that is in collection. And when a user(Client) want to send file send with own id and Id of that user(Client) want to send.
Related
My app can transfer files and messages between server and client. Server is multithreaded and clients simply connects to it. While file is being transferred, if sender sends a message, it will be consumed as bytes of file.
I don't want to open more ports,
Can I establish a new connection to the server for file transfer? Or I
should open a separate port for files.
I don't want to block communication while a file is being transferred.
The question was marked as a duplicate but its not, i am trying to send messages and files simultaneously not one by one. I can already receive files one by one. Read again.
Also, as server is multithreaded, I cannot call server socket.accept() again to receive files in new connection because main thread listening for incoming will try to handle it instead. Is there a way around?
Seems to me like trying to multiplex files and messages onto the same socket stream is an XYProblem.
I am not an expert on this, but it sounds like you should do some reading on "ports vs sockets". My understanding is that ip:port is the address of the listening service. Once a client connects, the server will open a socket to actually do the communication.
The trick is that every time a client connects, spawn a new thread (on a new socket) to handle the request. This instantly frees up the main thread to go back to listening for new connections. Your file transfer and your messages can come into the same port, but each new request will get its own socket and its own server thread --> no collision!
See this question for a java implementation:
Multithreading Socket communication Client/Server
you could use some system of all the lines of a file start with a string like this (file:linenum) and then on the other side it puts that in a file then to send text you could do the same thing but with a tag like (text)
Server:
Scanner in = new Scanner(s.getInputStream());
while(true) {
String message = in.nextLine();
if(message.length > 14 && message.substring(0,6).equalsIgnoreCase("(file:") {
int line = Integer.valueOf(message.substring(6).replaceall(")", ""));
saveToFile(message.substring(6).replaceAll(")","").replaceAll("<1-9>",""));
} else {
System.out.println(message);
}
}
I think that code works but I haven't checked it so it might need some slight modifications
You could introduce a handshake protocol where clients can state who they are (probably happening already) and what they want from the given connection. The first connection they make could be about control, and perhaps the messages, and remain in use all the time. File transfer could happen via secondary connections, which may come and go during a session. Having several parallel connections between a client and a server is completely normal, that is what #MikeOunsworth was explaining too.
A shortcut you can take is issuing short-living, one-time tokens which clients can present when opening the secondary connection and then the server will immediately know which file it should start sending. Note that this approach easily can raise various security (if token encodes actual request data) and/or scalability issues (if token is something completely random and has to be looked up in some table).
I am one server and multiple clients via threads. The client(s) send their message to the server. I have worked out how to make the server send the message back to client like a echo system. If I have two clients, I want them to send their message to the server and the server should send it to the client that did not send the message i.e. the other client. How would I go about send the message back to all the clients apart from the one that send the message?
When the message comes in, determine what the userID / other identifying id the incoming message is associated with. Then re-broadcast to all other sockets, but exclude the Socket associated with the ID that sent the message
Make at the server side a list with all the clients...
every time a new msg is received, then iterate the list and send the msg using the port of the socket as id...
I recently wrote a Chat program too. What I did was, I had a class ClientHandler that handles the connection for each individual client.
Inside ClientHandler I had a HashMap. I added each client that had connected to the HashMap, with the Key being the client id. I used a UUID rather than int for the client id.
Inside this handler class, I had a sendMessage(String str) method. Within this method, a for-each loop that loops through each ClientHandler object, checking the values inside the HashMap. Inside this for-each loop, I have an if statement that checks whether you are writing to the ClientHandler object with this id. If the check returns false, you go ahead and write the message on the PrintWriter and the message won't be sent to the client writing the message.
This worked for me. Might not work for you.
I'm developing a simple app with WebSockets.
Client side you can send input texts, while the server side is implemented via a Java class with annotated as ServerEndpoint. Here the input texts received get decoded and sent to all of the open sessions.
This works, but I want to store every message received by the server, so that when a new client connects, (using a method annotated with #OnOpen) it receives all the messages that has been sent while he was "offline". Where can I store this messages without using a database?
Solved it by using Singleton pattern. I created a Singleton class that stores a List, which gets updated in the onMessage method. Then, in onOpen, the messages stored get sent to the client that just opened the connection with the socket.
I have SMPP server, use CloudHoper.
When I get a message I should return a delivery report.
Please, tell me, how I can do it?
At this moment I return SubmitSmResp...
Of course you still need to answer the SubmitSm PDU with a SubmitSmResp PDU as you do now.
A delivery report is a "special" DeliverSm PDU which is generated in your SMPP server and sent additionally to your client. See SMPP 3.4 Appendix B how it is formatted (https://github.com/twitter/cloudhopper-smpp/blob/master/src/etc/SMPP_v3_4_Issue1_2.pdf). You also need to set esmClass of the DeliverSm PDU to 0x04 to indicate it's a delivery report.
If your client is using a transceiver bind, you can use the same session to send the DeliverSm PDU to, otherwise you need use the clients receiver session. If no active session is available you need to queue the DeliverSm PDU.
The main question is when to send the delivery report. First of all, you may send only a delivery report, if the client requested one, by setting the 4th bit of the SubmitSm esmClass.
Although, if your client is using a transceiver connection, don't send it directly in the firePduRequestReceived handler. The client may receive it before it receives the SubmitSmResp. Additionally this delivery report would not have more value than the SubmitSmResp itself.
So there are three cases when you may generate this delivery report and queue it until you have a proper session from your client to send it to:
1) When you receive some external event indicating that the former SubmitSm was actually processed (e.g. delivered) by it's destination.
2) When you are able to forward the SubmitSm to the next processing unit.
3) When you detect any error or the SubmtSm expired
Create a DELIVER_SM for that message and send that to the client.
I am trying to write a client server application that communicate using Message Objects(Message Class is defined in my application). there is a scenario in which i want to transfer file between them. First I must send a message to client to notify it about specific file information and after that the file itself is going to be written to channel.
The problem is how can I handle this scenario in client?
Is it a good solution to remove Message handler after receiving message and replace it with a byte array handler?
what are the alternatives?
Sure you can just modify the pipeline on the fly. We do something similar in our portunification example[1].
[1] https://github.com/netty/netty/blob/4.0/example/src/main/java/io/netty/example/portunification/PortUnificationServerHandler.java