WebSocket client API

Pavel Rappo pavel.rappo at oracle.com
Wed Sep 2 23:30:02 UTC 2015


Hi Andrej, thanks for your reply!

> On 2 Sep 2015, at 21:17, Andrej Golovnin <andrej.golovnin at gmail.com> wrote:
> 
> Just because you don’t see usages for it, it does not mean that others don’t need
> it.

I couldn't agree more. That's the main reasons we have this review. To tease out
things we've completely forgotten, haven't foreseen, etc.

> We have an application which already make use of it. And if you don’t add
> at least the #ping(ByteBuffer) method, it would not be usable for us and we will
> stay with JSR 356.

So you need the ability to send pings and unsolicited pongs. Do you handle pong
replies from the server? If so, do you control their arrival times and their
consistency with previous pings sent? What about unsolicited pongs from the
server?

Let me explain why I ask this. To be honest, one of the reasons I though we
might not need to expose keep-alive features in the first iteration of the API,
is that ping/pong exchange has certain rules to follow [1, 2]. And someone needs
to check these rules are followed. It's either implementation or API users or
both. Well, I decided it's not a particularly good idea to force API users
follow and track these rules.

I will have to consider this again. Thanks for pointing out the importance of
user accessible pings/pongs!

-------------------------------------------------------------------------------
[1] https://tools.ietf.org/html/rfc6455#section-5.5.2
[2] https://tools.ietf.org/html/rfc6455#section-5.5.3

-Pavel





More information about the net-dev mailing list