2

I need to write a application that can send push notifications at clients. But sometimes clients are disconnected, so I'd like to store notifications and send them to clients when they reconnect.

Is there a way to achieve this ? I need a way to know if client is present before sending, OR a way to know if a notification is well received. And my notifications are client specific.

I can't show off a lot of code, but I'd like to use something like this :

@Autowired
private SimpMessagingTemplate messagingTemplate;

public void sendPush(Long clientId) {

    messagingTemplate.convertAndSendToUser(clientId, "/queue/reply", myMessage);
    // -> how do I know if message is received ?
}

I use spring-websocket and stomp-endpoint.

Thank you !

Oreste Viron
  • 3,592
  • 3
  • 22
  • 34
  • 1
    do your clients have a client program they run on their system? do you have control of that code? if so, your path of least resistance will be to implement code that pulls in (or requests) the messages from the server when the client connects - which should already be there. then the server will know that the message was pushed. – Richard Barker Jun 14 '16 at 20:53
  • How the server can know if a message must be send to the client if it doesn't know when the client has received pushed message ? – Oreste Viron Jun 14 '16 at 21:07
  • 1
    The client tells the server "hey! i'm here!" when it connects. The server then says "ok; here take these messages!" to which the client replies "ok I got them; thank you!" the server is waiting for the client to tell it that it received the message -- until then the server doesn't and cant possibly know whether or not the client has gotten the messages. If i send you a letter, and you don't send one back, how do I know you got the letter I sent you? That problem, as I understand it, is the same problem TCP solves over UDP. – Richard Barker Jun 14 '16 at 21:15
  • The websockets is full duplex, so the server must know if a client is connected or not. If the client is connected, we can assume that he received the message. The server must be able to know if, when he must send a message, he must store the message for later (the client is disconnected), or send it (the client is connected). It is this feature I try to implement. – Oreste Viron Jun 14 '16 at 21:21
  • 1
    I see now. It doesn't know when the client disconnects though correct? – Richard Barker Jun 14 '16 at 21:26
  • Yes, the client can send a disconnect message, but I'cannot be sure at 100% it will do that. – Oreste Viron Jun 14 '16 at 21:33
  • You can be 100% sure the client has disconnected when the server throws a SocketClosed or StreamClosed exception, though, which should be getting thrown and caught somewhere. That's where you tell your system to start storing messages for that client. What you can't be sure of at that point is what caused the socket to close. But that shouldn't matter because you know you're not connected anymore. – Richard Barker Jun 14 '16 at 21:35
  • Yes, that is a solution but if I do so, I must maintain a pool with every client connected, and the disconnection is handled on the websocket level, not on the stomp level. I will let the question open in case someone has a alternative solution to achieve this. – Oreste Viron Jun 14 '16 at 21:46
  • My only other idea is to try to send the messages regardless of the clients known connection status. If sending fails then the client isn't connected and the server needs to wait for the next time it connects. – Richard Barker Jun 14 '16 at 21:50
  • Unfortunately, the server doesn't fail if the client is disconnected :-( – Oreste Viron Jun 14 '16 at 21:52

1 Answers1

0

Maybe you can expect to get an "ack" message from the user. You can keep all the message in a data structure and remove them from it only when you get the ack.

user6466490
  • 1
  • Yes, indeed that's a solution. But I'd prefere to keep the logic on the server side and do the minimum on the client side. – Oreste Viron Jun 14 '16 at 20:37