WAMP server websocket handshake

[Grim Lodaf]

Hi,

This is my understanding of how WAMP works: After establishing a websocket connection(i.e a successsful handshake),

the server sends a welcome message.Is this correct?

For a Autobahn.js, is the websocket protocol handshake any different than it is while using raw ws?

If so, how? And where can I get this sort of information?

I am writing a WAMP server(php), and I can't get autobahn to establish a connection.It works on raw ws though(without the Websocket-Server-Protocol header).

regards.

[Tobias Oberstein]

Am 03.03.2014 19:36, schrieb Grim Lodaf:
> Hi,
> This is my understanding of how WAMP works: After establishing a
> websocket connection(i.e a successsful handshake),
> the server sends a welcome message.Is this correct?

Autobahn|JS was recently upgraded to WAMP v2 "Basic Profile":

http://wamp.ws/spec/

For the spec to WAMP v1, that's linked in above page also.

With WAMP v2, the WAMP handshake starts with the client sending a HELLO
message.

> For a Autobahn.js, is the websocket protocol handshake any different
> than it is while using raw ws?

The WAMP handshake only starts after the WebSocket opening handshake has
already finished, and the WAMP handshake is already using WebSocket
messages.

> If so, how? And where can I get this sort of information?
> I am writing a WAMP server(php), and I can't get autobahn to establish a
> connection.It works on raw ws though(without the
> Websocket-Server-Protocol header).
> regards.

Ratchet, the only WAMP server I am aware of, currently is at WAMP v1.

So a WAMP v2 server would certainly be welcome!

An alternative might be to coordinate with Ratchet and consolidate
efforts there .. Chris?

Cheers,
/Tobias


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

[Chris Boden]

Ratchet currently supports WAMP/v1 but will support v2. Grim, if you're willing to contribute we can work through GitHub issues around the ticket. 

[Grim Lodaf]

Hello,
Very sorry for the late response, can't seem to keep up with time :(
@Tobias, I couldn't figure out why autobahn wouldn't accept the ws handshake, built my own (very very primitive) ws client.However I realized the issue might not be with autobahn at all, but with Chrome, it seems my server receives an empty header, but Firefox connects just fine. I've got a bone to pick with chrome...I shall try autobahn once again later.

@Chris, sure, I'd be glad to help, but I do need this project...

once again, apologies for the late reply.

[Tobias Oberstein]

Am 08.03.2014 07:28, schrieb Grim Lodaf:
> Hello,
> Very sorry for the late response, can't seem to keep up with time :(
> @Tobias, I couldn't figure out why autobahn wouldn't accept the ws
> handshake, built my own (very very primitive) ws client.However I

So you try to run AutobahnJS (WAMP v1 version) against Ratchet 0.3? That
is supposed to work.

> realized the issue might not be with autobahn at all, but with Chrome,
> it seems my server receives an empty header, but Firefox connects just
> fine. I've got a bone to pick with chrome...I shall try autobahn once
> again later.
>
> @Chris, sure, I'd be glad to help, but I do need this project...

Let me throw in my thoughts ..

From my perspective, it would be awesome to have

a) a complete and interoperable WAMP v2 implementation in PHP ..
b) on top of an evented networking framework ..
c) that implements the client roles (Caller/Caller/Publisher/Subscriber)

Regarding c), that means that in

Browser (Caller) ----> XXX (Dealer) ----> PHP* (Callee)

the XXX could be any WAMP v2 router. The library for PHP would provide
only *. Technically, this library would need to be a WebSocket _client_
that connects to XXX. Note that this doesn't mean that the PHP app based
on the library couldn't act as a "whatever" server at the same time. The
big advantage is that user can deploy any WAMP v2 router.

This is also mentioned here:
https://github.com/cboden/Ratchet/issues/168

Regarding b), my PHP insight/experience isn't sufficient. Ratchet is
based on React https://github.com/reactphp/react

Regarding a): I hope to find time to extend the Autobahn testsuite for
WAMP v2 soon. But I think the specification document of WAMP v2 is
already orders more complete and precise than WAMP v1.

Cheers,
/Tobias

>
> once again, apologies for the late reply.
>
>
> On Tuesday, March 4, 2014 9:33:53 PM UTC+3, Chris Boden wrote:
>
> Ratchet currently supports WAMP/v1 but will support v2. Grim, if
> you're willing to contribute we can work through GitHub issues
> around the ticket

> <https://www.google.com/url?q=https%3A%2F%2Fgithub.com%2Fcboden%2FRatchet%2Fissues%2F168&sa=D&sntz=1&usg=AFQjCNHKRa08HuGCubXR-HmJUwYmLth3Xw>.

> <https://groups.google.com/groups/opt_out>.

>
> --
> You received this message because you are subscribed to the Google
> Groups "WAMP" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email to wampws+un...@googlegroups.com

> <mailto:wampws+un...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/optout.

[Grim Lodaf]

So you try to run AutobahnJS (WAMP v1 version) against Ratchet 0.3? That
is supposed to work.

No, not against Ratchet, against my own server.

a) a complete and interoperable WAMP v2 implementation in PHP ..
b) on top of an evented networking framework ..
c) that implements the client roles (Caller/Caller/Publisher/

Subscriber)

Yes, I am implementing WAMP v2, in php.
The server uses Libevent. Currently working on multithreading using pthreads.

[Grim Lodaf]

Hello Tobias,
I have finally gotten Autobahn working with my server. However Chrome shows the error "unexpected message type 2" during the WAMP handshake. Firefox doesn't. The message type is WELCOME(2).Replacing this with any other valid WAMP message type throws the same error, for example EVENT throws "unexpected message type 36", and while this is appropriate,since the server is sending an event message during the handshake, it baffles me why it happens withthe welcome message.
Any ideawhat could be wrong?

[Tobias Oberstein]

There are 2 places in AutobahnJS where this error can origin ..
unfortunately with the same error message (which we should probably
change to make debugging such things easier):

https://github.com/tavendo/AutobahnJS/blob/master/package/lib/session.js#L893
https://github.com/tavendo/AutobahnJS/blob/master/package/lib/session.js#L941

The former is before session is established, the latter after.

With Chrome, can you post a screenshot of the Chrome WebSocket inspector
log?

Like the attached ..

/Tobias

[Grim Lodaf]

Solved.
The handshake response was being sent twice.
I don't know if anyone else has experienced this, but Chrome delays sending the ws handshake. A server which thus accepts and reads from a new connection in non-blocking mode therefore receives an apparently empty header.
It was while implementing a work-around for this that I got mixed up, and the ended up sending the welcome message twice.
Thanks for the tip.

[Tobias Oberstein]

Am 18.03.2014 13:23, schrieb Grim Lodaf:
> Solved.
> The handshake response was being sent twice.
> I don't know if anyone else has experienced this, but Chrome delays sending the ws handshake. A server which thus accepts and reads from a new connection in non-blocking mode therefore receives an apparently empty header.

I have never seen that. "Delay" until when?

Autobahn|Python set the socket to non-blocking mode .. there is no issue
in that.

[Grim Lodaf]

The delay is barely a second.I have experienced this before, and I have just confirmed it.Try the following script:

<?php

$socket = socket_create(AF_INET, SOCK_STREAM, SOL_TCP);

socket_set_option($socket, SOL_SOCKET, SO_REUSEADDR, 1);

socket_bind($socket, 0, 9000);

socket_listen($socket);

$connections = array($socket);

while (true) {

$changed = $connections;

socket_select($changed, $null, $null, 0, 10);

if (in_array($socket, $changed)) {

$new = socket_accept($socket);

//socket_set_nonblock($new);

$connections[] = $new;

$header = socket_read($new, 1024);

echo '>>>'.$header.'<<<';

$conn = array_search($socket, $changed);

unset($changed[$conn]);

}

}

The "server" echoes to the command line any data it receives.that's all it does, but it is only to illustrate a point.

By my trial, it echoes the ws header, both from Chrome and Firefox, every time.

Now try it with the socket_set_nonblock()  uncommented.

I observe a very curious behavior: Intemittently, and depending on the order in which either chrome or firefox made the connection first, the headers will be empty,

more often than not.

Reconnection attempts are made by refreshing the page repeatedly.

Perhaps it is a php issue?

[Tobias Oberstein]

> Now try it with the _socket_set_nonblock() _ uncommented.

Sorry, I don't use PHP and have no time checking it out ...

> I observe a very curious behavior: Intemittently, and depending on the
> order in which either chrome or firefox made the connection first, the
> headers will be empty,
> more often than not.
> Reconnection attempts are made by refreshing the page repeatedly.
> Perhaps it is a php issue?

Yes, I guess so. At least I can confirm to you that I have never seen
such issues with Chrome .. on no system.

However, to rule out any DNS issues, you might try using this

ws://127.0.0.1:9000

instead of

ws://localhost:9000

in your JS client. This sometimes induces a delay (for me, on my Windows
box) ..


Btw: are you doing a PHP WAMP2 _client_ also?

Is there even a PHP WebSocket _client_ library?

Another question: any reasons you are not using React, but libevent "raw"?

As far as I understand, React not only provides an evented networking
layer, but also Deferreds ..

Hope you find out whats going on .. sorry for not being more helpful ..

/Tobias

> On Tuesday, March 18, 2014 3:27:47 PM UTC+3, Tobias Oberstein wrote:
>
> Am 18.03.2014 13:23, schrieb Grim Lodaf:
> > Solved.
> > The handshake response was being sent twice.
> > I don't know if anyone else has experienced this, but Chrome
> delays sending the ws handshake. A server which thus accepts and
> reads from a new connection in non-blocking mode therefore receives
> an apparently empty header.
>
> I have never seen that. "Delay" until when?
>
> Autobahn|Python set the socket to non-blocking mode .. there is no
> issue
> in that.
>
> > It was while implementing a work-around for this that I got mixed
> up, and the ended up sending the welcome message twice.
> > Thanks for the tip.
> >
>

[Grim Lodaf]

The issue above was not with chrome, but a documented php bug while using non-blocking sockets.I've found letting libevent handle the IO solves it.
Thanks for the help anyway.
I had no plans of making a php WAMP/ws client library, but when I'm done with this, and I get some time, perhaps...
Reasons why I'm not using React: -AFAIK, React has no support for SSL/TLS. It would be easier to implement this if I wrote the code from the ground up.
                                                  -I was hoping to implement multi-threading.

[Chris Boden]

React does not support SSL/TLS. Implementing it in PHP in an async way was difficult but we managed to find a way to do the SSL handshake asynchronously. After that we still say major performance issues. Thus we decided SSL/TLS would best be proxied by Nginx/HAProxy/Varnish/etc in front of React instead - much faster. With Hack perhaps this can be looked at again. 

Grim, may I suggest taking another look at React? With many contributors and hundreds of man-hours through a common interface we've implemented an async I/O event loop with support for various Streams, LibEvent, and LibEv implementations and overcome common PHP-isms such as the one you've experience above. 

Tobias - yes, React has a deferred library called react-promise that supports the A+ specification. It has no dependancies and is unit tested. 

[Grim Lodaf]

Hello Chris,

React does not support SSL/TLS. Implementing it in PHP in an async way was difficult but we managed to find a way to do the SSL handshake asynchronously. After that we still say major performance issues. Thus we decided SSL/TLS would best be proxied by Nginx/HAProxy/Varnish/etc in front of React instead - much faster. With Hack perhaps this can be looked at again. 

I have been working on handling the TLS protocol messages in php(have gotten as far as client key exchange, change_cipher_spec and the finished messages.), then using the openssl functions to handle the actual decryption/encryption. I do not know how PHP handles listening on secured transports internally, but I suspect much of the same happens. The majority of the work is done by the openssl library. Hence I do not think the performance lag is any much more than listening on a secured transport in php itself(Although I've noticed it takes as much as 2s to decrypt the pre_master_key, but then again this only happens once in the handshake.). Please correct me if I am wrong.

With Hack perhaps this can be looked at again.

You say you managed to find a way to do the TLS handshake asyncronously? Perhaps we can work together on this then? 

[Tobias Oberstein]

Hi Chris,

> Tobias - yes, React has a deferred library called react-promise that
> supports the A+ specification. It has no dependancies and is unit tested.

Ah, neat! Does Ratchet make use of that?

IMHO e.g. for the "Caller" role on WAMP v2, having a Promise based API
is a very natural thing. Also in general. Well, maybe I am spoiled;)

/Tobias

[Chris Boden]

Hi Tobias,

Ratchet as is does not use any promises. For the new Session component I'm writing it will, as well as the WebSocket client in development, and I'm sure once I get around to implementing WAMPv2 I'll follow your lead and use them there. 

Grim: https://github.com/reactphp/react/pull/119