Handling of empty frames '[]'

[Vanja Bucic]

We have been using Faye ruby library to connect to CometD servers.

Lately we have been noticing odd errors and disconnects, and after updating CometD to version >3.1.1 total incompatibility.

After some heavy digging I figured out that Faye is periodically sending empty frames (as a form of PING to appease some proxies), and CometD is starting to really dislike it.

The nail in the coffin was the change you made in issue #721 (Optimize /meta/connect handling during processing of another request) where you explicitly stated:

private void processMessages(S wsSession, ServerMessage.Mutable[] messages) throws IOException {
            if (messages.length == 0) {
                throw new IOException();
            }
...
}

Pings in the form of '[]' text frames are throwing IO exceptions as of 3.1.2, and even before that they would schedule the session for expiration as a fall-through behavior causing premature session sweeps.

My question is: are empty frames prohibited by the specification, or is the crackdown on them totally unintentional?

Thanks.

[Simone Bordet]

Hi,

The Bayeux specification does not explicitly forbids them, but neither
defines them, so it was a real shot in the dark for the Faye Ruby
library to send them and expect that a Bayeux server would support
them.

To send a "ping"-like message is actually fairly easy by means of well
defined Bayeux messages: either a /meta/connect message, or a service
message.

The /meta/connect message ping would have this form:
{
"channel": "/meta/connect",
"timeout": 0,
...
}
The timeout=0 field tells the server to not hold the message, that
therefore is replied to immediately.

The service message ping would have this form:
{
"channel": "/service/ping",
...
}
The service channel used may be any service channel for which the
application knows it does not have any effect on the server.
Can be "/service/ping" or "/service/does_not_exist" or "/service/kdhiwf65", etc.
Being a service message it is replied to immediately by the server.

I would recommend that the Faye Ruby authors modify the library to
support either case - I have a preference for the service message
because it can be sent at any time, while the /meta/connect has
restrictions on when it can be sent.

--
Simone Bordet
----
http://cometd.org
http://webtide.com
Developer advice, training, services and support
from the Jetty & CometD experts.

[Vanja Bucic]

Thank you,

I'll advocate for that with the Faye group, and update this topic with any news.

--
--
You received this message because you are subscribed to the Google Groups "cometd-users" group.
To post to this group, send email to cometd...@googlegroups.com
To unsubscribe from this group, send email to cometd-users...@googlegroups.com
For more options, visit this group at http://groups.google.com/group/cometd-users

Visit the CometD website at http://www.cometd.org

---
You received this message because you are subscribed to the Google Groups "cometd-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cometd-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Vanja Bucic]

Faye has removed the empty frame ping functionality via commit [https://github.com/faye/faye/commit/45a1731cc2ce7ea8e9b4dc3557266e424cd637f6]

Lowering the timeout on the server will be the suggestion for proxies that require more activity.

Thanks to everyone involved...