Problems with websockets API on Mac OSX

[Jonathan Martin]

Hello,

I'm trying to setup a test install on my mac for streaming plugin via websocket API, but I'm hitting a problem.

I installed with following:

brew install jansson libnice openssl libusrsctp libmicrohttpd libwebsockets cmake opus libogg libcurl glib pkg-config gengetopt autoconf automake libtool
# This installs libwebsockets 2.4.1
# Then from janus @master#c408dd57ba874378e7fedb9a17b5e14f17fa6f8f
./configure  --prefix=/usr/local --disable-all-plugins --enable-plugin-streaming PKG_CONFIG_PATH=/usr/local/opt/openssl/lib/pkgconfig
make
sudo make configs
sudo make install

Janus starts properly with default config, but then a simple:

ws = new WebSocket('ws://192.168.0.12:8188/janus', 'janus-protocol')

ws.onmessage = function(msg) {
 console.log(msg.data);
}
ws.send(JSON.stringify({janus: 'create', transaction: 'c408dd57ba874378e7fedb9a17b5e14f17fa6f8f'}))

Will not return me anything, while on janus logging with level 7, I get all this:

[WSS-0x7febe2f03ce0] 20 (LWS_CALLBACK_FILTER_PROTOCOL_CONNECTION)

[WSS-0x7febe2f03ce0] 53 ((null))

[WSS-0x7febe2f03ce0] WebSocket connection opened from 192.168.0.12

Checking if 192.168.0.12 is allowed to contact janus interface

Yep

[WSS-0x7febe2f03ce0] WebSocket connection accepted

[WSS-0x7febe2f03ce0]   -- Ready to be used!

[WSS-0x7febe2f03ce0] Got 75 bytes:

[WSS-0x7febe2f03ce0] First fragment: 75 bytes, 0 remaining

{"janus":"create","transaction":"c408dd57ba874378e7fedb9a17b5e14f17fa6f8f"}

[WSS-0x7febe2f03ce0] Done, parsing message: 75 bytes

Got a Janus API request from janus.transport.websockets (0x7febe4300000)

Transport task pool, serving request

Creating new session: 1736805532720348

Sending Janus API response to janus.transport.websockets (0x7febe4300000)

• HTTP API works
• Exact same commands works on a recent build on linux of course :-)

Would you have any idea of what could be happening please?

Thanks & Cheers

[Lorenzo Miniero]

Not a Mac user so can't help, sorry... may be an issue with libwebsockets in that environment. The fact that HTTP works is unrelated as they're different libraries and different transport modules, but at least confirms the core itself would respond.

I'm wondering if you're encountering the issue this user fixed with this PR here:

https://github.com/meetecho/janus-gateway/pull/884

We ended up not merging it because it caused the CPU on Linux to spike to 100%, and so was not a valid solution to the problem.

L.

[Jonathan Martin]

Thanks a lot,

This is quite helpful, pointing me in the right direction and showing that there is indeed an issue!

I guess I will have to dive in a bit, maybe an occasion to contribute? ;-)

Best regards,

Jonathan

[Lorenzo Miniero]

Il giorno venerdì 10 novembre 2017 09:13:05 UTC+1, Jonathan Martin ha scritto:

Thanks a lot,

This is quite helpful, pointing me in the right direction and showing that there is indeed an issue!

I guess I will have to dive in a bit, maybe an occasion to contribute? ;-)

I definitely always welcome contributions! :-)

Lorenzo

[Jonathan Martin]

OK,

I did investigate a bit; when janus core calls the send_message callback (janus_websockets_send_message), a call to lws_callback_on_writable(...) is performed and supposed to wake up the common callback.

But for obscure reasons, it does not. Off course the fix proposed in the PR you mentioned "works", but it is not a proper way of fixing the issue ^^ (same as calling janus_websockets_common_callback directly from janus_websockets_send_message...).

There is an issue raised in 2015 (!!!) against libwebsockets which did not seem to reach any conclusion: https://github.com/warmcat/libwebsockets/issues/314

I posted an update on that issue, let's see how this gets...

Cheers,

Jonathan

[Jonathan Martin]

Something to add:

As someone mentioned in the libwebsockets issue, there seem to be indeed some differences on the implementation of poll between mac and linux.

Look at this stackoverflow: https://stackoverflow.com/questions/32192063/differences-in-poll-between-linux-and-os-x-when-pollfd-is-changed-on-another-t

I don't pretend to be an expert on poll, but it seems that there are discussions about modifying the poll fds from another thread, which would be quite undefined behavior.

This Curl issue also is a bit worrying: https://github.com/curl/curl/issues/1057

They have seen changes of behavior of the poll function twice in a short period!

All to say, calling lws_callback_on_writable(client->wsi) from another thread may not be as safe as it seems... :-(

Jonathan

--
You received this message because you are subscribed to a topic in the Google Groups "meetecho-janus" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/meetecho-janus/HsFaEXBz4Cg/unsubscribe.
To unsubscribe from this group and all its topics, send an email to meetecho-janus+unsubscribe@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Marshall Quander]

This is reminiscent of a problem I had trying to get Janus websockets working on WSL -- see https://groups.google.com/forum/#!searchin/meetecho-janus/wsl%7Csort:date/meetecho-janus/j1TRH6OpwF4/OD4TwI3HBwAJ

I never did track down the problem, though.

[Jonathan Martin]

Hi guys,

Here is the follow up on that issue.

After some digging, and thanks to Andy from libwebsockets team, we identified a problem coming from the difference of implementation of the poll() system call, which would allow to update the file descriptors expected events during an ongoing poll on linux, but not on BSD-like systems like OSX. Could it be the same on Windows? Don't ask me :-)

So now Andy has pushed a change on master that fixes that issue, which we tested with several concurrent websockets on mac and linux. And now I gets my answers to janus requests!!!

If you are interested into the issue, just look at that thread: https://github.com/warmcat/libwebsockets/issues/314

Note that on master, there is another nice feature present as well: now, when a client to the LWS library try to mark a websocket as writable with the lws_callback_on_writable() API, provided that a LWS_CALLBACK_GET_THREAD_ID callback is implemented to identify who's the caller, the library would post automatically an event to the poll to wake it up directly instead of waiting for the next timeout. At the moment, as the websocket service timeout is set to 50ms, you would gain quite a bit in reactivity by implementing that callback! I'm putting together a pull request for that.

But now, using libwebsockets from master instead of brew's version resolves the issue.

[Lorenzo Miniero]

Thanks for the update, and good to know this was fixed eventually!

Lorenzo

[Marshall Quander]

Update: Janus does appear to work correctly on WSL with this patch! Excellent.

On Thursday, November 9, 2017 at 12:55:55 PM UTC-8, Jonathan Martin wrote:

[Marcel]

Hi Guys,

How did you get libwebsockets compiling on the mac?

I'm having some issues with openssl

[  1%] Building C object CMakeFiles/websockets.dir/lib/tls/openssl/openssl-client.c.o

/Users/marcel/libwebsockets/lib/tls/openssl/openssl-client.c:283:25: error: implicit declaration of function 'TLS_client_method' is invalid in C99 [-Werror,-Wimplicit-function-declaration]

        method = (SSL_METHOD *)TLS_client_method();

                               ^

/Users/marcel/libwebsockets/lib/tls/openssl/openssl-client.c:283:25: note: did you mean 'TLSv1_client_method'?

/opt/local/include/openssl/ssl.h:1872:19: note: 'TLSv1_client_method' declared here

const SSL_METHOD *TLSv1_client_method(void);    /* TLSv1.0 */

                  ^

/Users/marcel/libwebsockets/lib/tls/openssl/openssl-client.c:283:11: error: cast to 'SSL_METHOD *' (aka 'struct ssl_method_st *') from smaller integer type 'int' [-Werror,-Wint-to-pointer-cast]

        method = (SSL_METHOD *)TLS_client_method();

                 ^

2 errors generated.

Marcel

[Marcel]

To answer my own question. 

I disabled openssl 

cmake -DLWS_WITH_SSL=0 ..

[Jonathan Martin]

Or if you have the brew version of openssl you can try this:

PKG_CONFIG_PATH=/usr/local/opt/openssl/lib/pkgconfig cmake ..

--