I have a problem like two clients should be accessing my web application.
My first question is how can i know that two clients exist.
If two clients exist i should have a communication as mentioned below.
Client1 should write
once client1 writes then client2 should read it and will respond
once client2 writes then client1 should read it and will respond
in this pattern my communication should happen.
Any help will be appreciated...Thanks in advance
Create an HttpSessionListener which will maintain a set of active sessions. When a servlet gets a request from client1 save request body in a client1 session attribute then look for client2 session in active session set, if found take body (previous client2 request) from there and send it as a response to client1.
i think you are looking for jsr 356.
Related
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 am developing a chat server through netty websocket. Our client side is mostly browser based.
What's happening is, when I refresh the browser it closes the websocket connection and losses everything and creates a new socket when browser is loaded again.
Is there any mechanism which shall reconnect with my previous websocket session at server side.
I am planning to cache all user session and if received any connection close event from client side then without deleting user session information waiting more 30-60s,in between if server receive new connection request from same client(detecting through cookies id) then replacing by new session information.
My problem is if I do not remove session when server receive connection close event , other read/write operation through this session's channel creating problem.
What I can understand from following is
My problem is if I do not remove session when server receive connection close event , other read/write operation through this session's channel creating problem.
Your chat logic is tightly coupled with the channel/channel handler object.
If you can move the chat logic to a separate class which I call "Session" and have onEventXXX callbacks in that class and have chat logic on top of it (separate chain of classes may be), when there is a write operation, write the message using session.write(...). The "Session" have to delegate it to the underlying channel.
When the underlying channel is closed, you can keep the "Session" object for while and reattach with it's new channel.
To do this you might need to create a separate Netty handler called "SessionHandler" and process channel events/session creation.
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.
Lets say there are two receiver session from same application to a SMPP over different TCP ports.
Message is sent to application and reply is (i.e deliver_sm_resp) is coming to SMPP via the other session
Is this possible or reply should be come over the same SMPP session?
No, the deliver_sm_resp should be sent back using the same session as the deliver_sm was received on.
The response is linked with the request by a sequence number that is incremented with each request on the session so the it only makes sense within the same session.
I am trying to create a client socket connection, when a new request is created a connection is established & data transfer takes place. Is there any way that once the Connection is created it will be open for all time ? If yes then how can create it & also how can I identify what request is sent & got the response for the same request?
Looking forward for your response.
You can create a connection for all time, by not closing it. However the trick is detecting when a connection has failed. e.g. the client/server has restarted.
If you want to match requests to responses you can use a request id, but a much simpler approach is to only send one request at a time per socket, that way the response you get is for the request you just sent. You can use more than one socket in a thread if this is required.