Websocket Ping/Pong

[Anoop K]

Current model expects caller to set callbacks (SetPingHandler/SetPongHandler) to process ping/pong msgs. If caller want to block on ReadMessage and want to come out if a ping/pong control message arrives, currently there is no clean way ?

How about making ping/pong handlers optional and propagating control msgs up to the caller if no callbacks are set ?

Thanks

Anoop 

[Anoop K]

I was trying a toy streaming replicator on top of websockets. 

• Client initiates websocket conn to a server.
  
• Server streams updates to client in real-time and send ping control msgs periodically(if there are no updates). 
  
• The only msg send back by client back is pong.
  
• Now if i want a goroutine at server side to do something like below, then control msg may need to be propagated ?  
  

c := time.Tick(pingInterval)

for  _ := range c {

       err := ws.WriteControl(Ping...)

           :

       _, _, err := ws.ReadMessage()

      if err is timeout {

                do something

      } else {

             do ...

     }     

}

Again this may not be a realistic requirement. I asked about the API just to understand why control msgs are not propagated to caller.

Anoop

[Anoop K]

Thanks for the explanation. I was able to reorganize code and solve it using ping/pong callbacks.

 I will look in to this one and the dialer APIs once I get some time.

Thanks

Anoop

---------- Forwarded message ----------
From: Gary Burd <gary...@gmail.com>
Date: Sun, Nov 10, 2013 at 11:16 PM
Subject: Re: [gorilla] Re: Websocket Ping/Pong
To: goril...@googlegroups.com
Cc: ga...@beagledreams.com

The fragment of code assumes that the peer responds to each ping with a pong. This assumption is supported by section 5.5.2 of the RFC which says that an endpoint MUST reply to a ping with a pong. Section 5.5.3 seems to contradict this by saying that an endpoint MAY under some circumstances elect not to send a pong in response to a ping. It will be interesting to find out how this works in practice with various clients.

You can implement the keep-alive ping with two goroutines:

c := time.Tick(pingInterval)

for  _ := range c {

       if err := ws.WriteControl(Ping...); err != nil {

                     handle error 

                 }

          }

          -----

          ws.SetPongHandler(func(string) error { return ws.SetReadDeadline(time.Now().Add(pingInterval + slop)) })

           for {

               if _, _, err := ws.NextReader(); err != nil {

                  handle error

               }

          }

There are two reasons why I used callbacks to handle control messages. The first is that callbacks avoid the need to buffer control messages. The second is that it's easier to write functions like ReadJSON when control messages are handled separately from data messages.

The proposed feature does fit with the existing API. I will accept a pull request for the feature.

--
You received this message because you are subscribed to a topic in the Google Groups "Gorilla web toolkit" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/gorilla-web/SHhlUyQlHpI/unsubscribe.
To unsubscribe from this group and all its topics, send an email to gorilla-web...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.