0

I have a Websocket connection being served from http-kit (Clojure, and it works great). I send pings from the client to make sure we're still connected, and everything works fine there. My question is, do people bother pinging client from server in these cases?

I was trying to set something up to remove the channel from the server if I didn't get a response, but it's not very functional-friendly to set up timed processes and alter state to track the ping-pong cycle, so it was getting a little ugly. Then I thought, the server can handle hundreds of thousands of simultaneous connections, should I just not worry about a few broken threads? How do people typically handle (or not handle) this?

TrivialCase
  • 1,060
  • 2
  • 14
  • 27

1 Answers1

1

The WebSocket protocol itself has heart beating to keep the connection alive. If you wanted an additional layer on top of that you could use the STOMP protocol, which coordinates heartbeats between client/server.

The one STOMP implementation I know of for the JVM is Stampy. There’s one for JS too, stompjs. Note: the heartbeat implementation differs between these libs, I believe the Stampy one is incorrect. You’d have to roll your own.

Brian Baritonehands Gregg
  • 376
  • 2
  • 4
  • Thanks! I think this is pretty much what I was looking for. I'm thinking that the typical timeout is fine, but I worry about maintaining some huge list of channels even though many of them may have dropped - it's probably engineering a solution to a problem that won't exist. – TrivialCase Apr 14 '18 at 12:52