It turned out that I still have complications to send a valid PongFrame
while implementing a heart-beat mechanism on my websocket client.
Here is the relevant snippet:
// My WebSocketApplication subclass
@Override
public void onPong(WebSocket socket, byte[] bytes) {
System.out.println("*** *** onPong() *** ***");
super.onPong(socket, bytes);
}
// My client's PongFrame send invocation
webSocket.send(new DataFrame(new PongFrameType(), new byte[0],
true).getBytes());
Syntax highlighted version:
http://pastebin.com/ADSGKBxS
All I want to accomplish is to let the client send a valid PongFrame, such
that my overriden onPong() callback gets invoked on the server side.
Would you be so kind and provide a snippet showing a sending of a valid
PongFrame? :-)
2012/1/9 Philipp Tarasiewicz <justphilmusic_at_googlemail.com>
> Hi Ryan,
>
> I haven't any code that is worth mentioning, since I've obviously
> misinterpreted the related API docs.
>
> My initial thoughts after having studied the docs were like:
> Grizzly automatically performs ping/pong cycles every x seconds to
> maintain the connection to every connected remote client and
> correspondingly invokes the related callback methods in the
> WebSocketApplication class.
> - onPing(WebSocket socket, byte[] bytes) : Server is about to ping
> WebSocket 'socket' by sending 'bytes' bytes.
> - onPong(WebSocket socket, byte[] bytes) : Server has received pong
> information 'bytes' from remote client connected to WebSocket 'socket'.
>
> So, I've overriden these methods in my WebSocketApplication subclass (just
> for logging purpose), started the server, connected a client to it and have
> been expecting that server/client will automatically perform ping/pong
> cycles every x seconds.
>
>
> But finally, after having read your and Justin's responses + having a
> closer look at your corresponding code (just cloned the repo), it is
> completely enlightening that it could not work this way.
>
> In particular, I've realized how you send the ping / pong frames.
> Consequently, it shouldn't be a big deal for me to implement the behavior
> that I had initially expected.
>
> Nevertheless, I will also log a feature request. :-)
>
>
>
> There is one more question I'm interested in. But, I should probably ask
> it in a new thread since it does not related to this topic.
>
> Thank you guys for your help!
>
> Phil
>
>
> 2012/1/9 Ryan Lubke <ryan.lubke_at_oracle.com>
>
>> On 1/9/12 7:19 AM, justphilmusic_at_googlemail.com wrote:
>>
>>> Hi Ryan!
>>>
>>> Until now I've just played around with the WebSocketClient included in
>>> Grizzly's 2.1.8 WebSocket API. So, it's the websocket version that the
>>> WebSocketClient class is using.
>>> I haven't used a brower yet.
>>>
>> To go back to your original question, I've locally tested that pings are
>> responded to automatically, however, I'm making some changes to
>> make sending pings a little more straight forward.
>>
>> Can you share your code? Would like to see what you're doing different.
>>
>>
>>> The question is:
>>> Does Grizzly's WebSocket implementation perform any connection
>>> maintainance / heart-beating under the hood or do I have to implement
>>> the logic by myself?
>>>
>> At this point, there is no heart-beat feature. However, it probably
>> wouldn't
>> be a bad feature to offer. I would recommend logging a feature request.
>>
>>
>>>
>>> Best regards,
>>> Phil
>>>
>>
>>
>