Running the EventBus straight on a WebSocket endpoint without SockJS

[tsuna]

To my surprise it seems that the current APIs only allow one to bridge the EventBus over a SockJS end point.  Is there any reason there is no API to easily bridge it over a plain WebSocket end point?  For non-browser clients that would be better.

--
Benoit "tsuna" Sigoure

[Tim Fox]

You can use raw websockets with SockJS too

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

[tsuna]

I’d like to resurrect this thread.

There aren’t many SockJS client implementations out there. SockJS is
not a big layer on top of WebSocket (although the double JSON encoding
is annoying), but it creates friction for non-browser clients.

There should be a way to tell Vert.x “I want to bridge the EventBus
onto this WebSocket endpoint *and* also support SockJS on top of
that”. Right now you can only tell it “I want to bridge the EventBus
onto this WebSocket+SockJS endpoint”.

--
Benoit "tsuna" Sigoure

[Tim Fox]

I'm not sure exactly what you're asking... but if you're asking whether
you can connect to a SockJS endpoint using raw websockets on the client
side (no SockJS) then the answer is yes - that has always been true.

Here's an example of doing that in a test:

https://github.com/vert-x3/vertx-web/blob/master/src/test/java/io/vertx/ext/web/handler/EventbusBridgeTest.java#L988

[tsuna]

What I’m asking for a is for a pure-WebSocket EventBus bridge endpoint
that doesn’t require dealing with the small SockJS layer.

SockJS only makes sense for browsers. Non-browser clients shouldn’t
have to deal with the SockJS stuff. It creates friction to tell all
our users “you can connect to this WebSocket endpoint, but it’s
actually a SockJS endpoint, so you need to go through this little
SockJS dance to get things going”.

> For more options, visit https://groups.google.com/d/optout.



--
Benoit "tsuna" Sigoure

[David De La Harpe Golden]

The point is vertx sockjs support on the server is really already exposing a 'raw' websocket endpoint [just like reference nodejs sockjs server] - in addition to sockjs-dance-required websocket. No really it is. i distinctly recall hitting vertx eventbus over the bridge from c with libwebsockets at a previous job to stream financial data between systems, i.e. no sockjs knowledge on the client [though trivial but formally undocumented / subject to change vertx eventbus bridge message envelope knowledge required].

https://github.com/sockjs/sockjs-node#connecting-to-sockjs-node-without-the-client

note again, this is actually a different endpoint to the sockjs websocket endpoints the browser client uses.

It might be vaguely good to be able to only have the raw websocket endpoint switched on though for non-browser applications, last i checked both websocket and raw-websocket only switch on and off together. otoh it might just be confusing and doesn't matter much

https://github.com/eclipse/vert.x/blob/2.x/vertx-core/src/main/java/org/vertx/java/core/sockjs/impl/DefaultSockJSServer.java#L196

[Tim Fox]

On 23/05/15 00:30, tsuna wrote:
> What I’m asking for a is for a pure-WebSocket EventBus bridge endpoint
> that doesn’t require dealing with the small SockJS layer.
>
> SockJS only makes sense for browsers. Non-browser clients shouldn’t
> have to deal with the SockJS stuff. It creates friction to tell all
> our users “you can connect to this WebSocket endpoint, but it’s
> actually a SockJS endpoint, so you need to go through this little
> SockJS dance to get things going”.

What dance are you referring to? SockJS comes with a standard protocol
called raw websocket - which is exactly that, it allows you to connect
with a raw websocket. No dance required. Your clients don't need to know
that they're connecting to a SockJS endpoint.

Did you take a look at the link to the tests in my last reply, they
demonstrate this:

https://github.com/vert-x3/vertx-web/blob/master/src/test/java/io/vertx/ext/web/handler/EventbusBridgeTest.java#L988

As you can see we're creating a completely standard web socket
connection (no SockJS) on the client side and connecting to a server...
that's it. And this should work with any SockJS server which has the raw
websocket transport enabled:

There's some more info here:

https://github.com/sockjs/sockjs-client "Connecting to SockJS without
the client"

[tsuna]

On Fri, May 22, 2015 at 6:25 PM, David De La Harpe Golden
<david.delah...@gmail.com> wrote:
> The point is vertx sockjs support on the server is really already exposing a
> 'raw' websocket endpoint [just like reference nodejs sockjs server] - in
> addition to sockjs-dance-required websocket. No really it is. i distinctly
> recall hitting vertx eventbus over the bridge from c with libwebsockets at a
> previous job to stream financial data between systems, i.e. no sockjs
> knowledge on the client [though trivial but formally undocumented / subject
> to change vertx eventbus bridge message envelope knowledge required].
>
> https://github.com/sockjs/sockjs-node#connecting-to-sockjs-node-without-the-client
>
> note again, this is actually a different endpoint to the sockjs websocket
> endpoints the browser client uses.

Ah, I totally missed that!

On Sat, May 23, 2015 at 1:04 AM, Tim Fox <timv...@gmail.com> wrote:
> Did you take a look at the link to the tests in my last reply, they
> demonstrate this:

I did, but I obviously didn’t get it. Now I got it.

Thank you guys!

--
Benoit "tsuna" Sigoure

[Konstantyn Smirnov]

Is it still possible in 3.4.1?
The link down below is dead (404)

[Paulo Lopes]

The updated link is: https://github.com/vert-x3/vertx-web/blob/master/vertx-web/src/test/java/io/vertx/ext/web/handler/EventbusBridgeTest.java

[Konstantyn Smirnov]

Thanks for the link!

Another question though. I can access my sockJS endpoint's websocket like that:

   ws://192.168.0.120:8811/eventbus/websocket

On the server side I have the codez:

SockJSHandler sockJSHandler = SockJSHandler.create( vertx ).bridge( opts ){ BridgeEvent event ->
  event.complete true
  log.info "event: ${event.type()} -> ${event.rawMessage}"
}
Router router = Router.router vertx
router.route( '/eventbus/*' ).handler sockJSHandler
server = vertx.createHttpServer().requestHandler router.&accept

In my websocket client after connecting I'm sending a register request, which appears in server' log:

event: SOCKET_CREATED -> null
event: REGISTER -> [type:register, address:57dbf0113578394e8424ce69, headers:{}]

but the client's onFrameReceived()-listener is never invoked. I have a feeling, that I have to register a consumer insde the handler myself. Is that so?

[Konstantyn Smirnov]

For some reason the WS client recoginzed the event-bus frame as Binary and didn't fire the onTextFrame() listener.
I switched it over to more general onFrame() method and now it's working like charm in Android!