[Libwebsockets] Unable to communicate with node server over Websocket

sthustfo sthustfo at gmail.com
Mon Aug 18 17:34:13 CEST 2014


Hi Subi,

I got to know that in case of socket.io, one needs to obtain the id from
the nodejs server using HTTP GET and then use that id when connecting over
WS. How did you get the id? Did you use lws library or some other means?

Thanks.



On Mon, Aug 18, 2014 at 6:00 PM, Subi S S <andy.green at linaro.org> wrote:

>  Hi,
>
>
>
> I was able to make it work after changing the socket io path, I was
> connecting to wrong path.
>
>
>
> Thanks,
>
> Subi
>
>
>
> *From:* Andy Green [mailto:extracats at googlemail.com] *On Behalf Of *
> sthustfo
> *Sent:* Monday, August 18, 2014 3:26 PM
> *To:* Subi S S
> *Cc:* libwebsockets at ml.libwebsockets.orgo
> *Subject:* Re: [Libwebsockets] Unable to communicate with node server
> over Websocket
>
>
>
> Hi Subi,
>
>
>
> Apologies for the delayed response as I haven't checked my mails in a
> while. The sample nodejs server I used is mentioned in this mail thread in
> an earlier mail. Please check this thread.
>
>
>
> Cheers.
>
>
>
> On Mon, Aug 11, 2014 at 12:22 PM, Subi S S <andy.green at linaro.org> wrote:
>
> Hi Sthustfo,
>
>
>
> I am facing the same issue you were mentioning in the earlier email, could
> you please let me know how you recovered ?
>
> Also is it possible for you to share the sample nodejs server code you are
> trying ?
>
>
>
> Thanks,
>
> Subi
>
>
>
> *From:* Andy Green [mailto:extracats at googlemail.com] *On Behalf Of *
> sthustfo
> *Sent:* Wednesday, August 06, 2014 11:33 AM
> *To:* Andy Green
> *Cc:* libwebsockets at ml.libwebsockets.org
> *Subject:* Re: [Libwebsockets] Unable to communicate with node server
> over Websocket
>
>
>
> Hi Andy,
>
>
>
> Now able to communicate with the node server. There was a typo with the
> path value.
>
>
>
> -
>
> sthustfo
>
> On Tue, Aug 5, 2014 at 7:15 PM, Andy Green <andy at warmcat.com> wrote:
>
>
>
> On 5 August 2014 21:01:35 GMT+08:00, sthustfo <sthustfo at gmail.com> wrote:
> >Andy,
> >
> >Thanks for the suggestions. I did try putting one protocol structure,
> >and I
> >see the earlier behavior which is parsing error. I will keep looking
> >into
> >this. Meanwhile, I found a node.js and socket.io based server hosted
> >online
> >- appolo-chat-example.herokuapp.com/.
> >
> >I was able to capture the ws handshake messages using chrome.
> >
> >
>
> >   1. Request URL:
> >   ws://
> >
> appolo-chat-example.herokuapp.com/socket.io/?EIO=2&transport=websocket&sid=DSqTKgIc-CNbawicAAAB
> >   2. Request Method:
> >   GET
> >   3. Status Code:
> >   101 Switching Protocols
> >   4. Request Headers
> >      1.
> >      Provisional headers are shown
> >      2. Cache-Control:
> >      no-cache
> >      3. Connection:
> >      Upgrade
> >      4. Cookie:
> >      io=DSqTKgIc-CNbawicAAAB
> >      5. Host:
> >      appolo-chat-example.herokuapp.com
> >      6. Origin:
> >      http://appolo-chat-example.herokuapp.com
> >      7. Pragma:
> >      no-cache
> >      8. Sec-WebSocket-Extensions:
> >     permessage-deflate; client_max_window_bits, x-webkit-deflate-frame
> >      9. Sec-WebSocket-Key:
> >      SR0i9G/oRJdJSgAXjo5iOw==
> >      10. Sec-WebSocket-Version:
> >      13
>
> This is the release version of the protocol.
>
> So for the version of socket.io they're using anyway, it should be
> compatible with lws.
>
> -Andy
>
> >      11. Upgrade:
> >      websocket
> >      12. User-Agent:
>
> >   Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko)
> >      Chrome/36.0.1985.125 Safari/537.36
>
> >      5. Query String Parametersview sourceview URL encoded
> >      1. EIO:
> >      2
> >      2. transport:
> >      websocket
> >      3. sid:
> >      DSqTKgIc-CNbawicAAAB
> >      6. Response Headers
> >      1. Connection:
> >      Upgrade
> >      2. Sec-Websocket-Accept:
> >      dWoZ+rfisaRB50AzubuYJhd9FBk=
> >      3. Upgrade:
> >      websocket
> >      4. Via:
>
> >      1.1 vegur
> >
> >
> >-
> >sthustfo
> >
> >
> >On Tue, Aug 5, 2014 at 5:08 PM, Andy Green <andy at warmcat.com> wrote:
> >
> >>
> >>
> >> On 5 August 2014 19:25:11 GMT+08:00, sthustfo <sthustfo at gmail.com>
> >wrote:
> >> >Hi Andy,
> >> >
> >> >Is there a way to supress the protocols altogether? I tried to set
> >the
> >> >"*info.protocols
> >> >= NULL"* and forced use_ssl=0 when creating the context using
> >> >libwebsocket_create_context() but the program encounters a SIGSEGV
> >> >during
> >> > lws_context_init_client_ssl().
> >> >
> >> >Is there a way to just not send any protocols (they are optional?)
> >and
> >> >use
> >> >pure ws://?
> >>
> >> No, although you can negotiate with no protocol in the upgrade, in
> >lws the
> >> logical protocols contain the binding to the user callback, and the
> >first
> >> protocol is targeted for HTTP callbacks.
> >>
> >> So logical callbacks themselves are not optional in lws and you have
> >to
> >> give at least one when creating the context.
> >>
> >> However for client, you can give NULL as the protcol you're asking
> >for in
> >> libwebsocket_create_client() and he will upgrade with no protocol
> >header.
> >>
> >> Similarly in server, you may create a protocol struct whose name is
> >NULL,
> >> he will match for no protocol header in the client upgrade.
> >>
> >> So you can do what you want later, but in all cases must give at
> >least one
> >> protocol struct to the context so you can get any callbacks.
> >>
> >> -Andy
> >>
> >> >
> >> >Thanks.
> >> >sthustfo
> >> >
> >> >
> >> >
> >> >On Tue, Aug 5, 2014 at 4:11 PM, Andy Green <andy at warmcat.com> wrote:
> >> >
> >> >>
> >> >>
> >> >> On 5 August 2014 18:07:09 GMT+08:00, sthustfo <sthustfo at gmail.com>
> >> >wrote:
> >> >> >Hey Andy,
> >> >> >
> >> >> >Thanks for the quick response. I am not aware of the compliance
> >> >status
> >> >> >of
> >> >> >socket.io but am trying to find out the same. Meanwhile, here is
> >the
> >> >> >client
> >> >> >log with debug level 1023.
> >> >>
> >> >> It seems to send us junk (|)
> >> >>
> >> >> [411975:0442] CLIENT: nonblocking connect retry
> >> >> [411975:0442] CLIENT: libwebsocket_client_connect_2
> >> >> [411975:0442] CLIENT: libwebsocket_client_connect_2: address
> >> >127.0.0.1
> >> >> [411975:0442] CLIENT: connected
> >> >> [411975:0473] PARSER: WSI_TOKEN_NAME_PART '|'
> >> >> [411975:0473] INFO: Unknown method - dropping
> >> >> [411975:0474] WARN: problems parsing header
> >> >> [411975:0474] INFO: closing connection at
> >LWS_CONNMODE...SERVER_REPLY
> >> >>
> >> >> If you didn't tell your server to support the protocols the test
> >> >clients
> >> >> uses, you wouldn't get any success anyway.  But it should just
> >close
> >> >the
> >> >> connection not send junk.
> >> >>
> >> >> If you want to look further into it send the packet traces but I
> >> >guess it
> >> >> only supports some older RFC version of websockets.  Which is
> >> >probably a
> >> >> sign it's long unmaintained.
> >> >>
> >> >> -Andy
> >> >>
> >> >> >-
> >> >> >sthustfo
> >> >> >
> >> >> >On Tue, Aug 5, 2014 at 3:29 PM, Andy Green <andy at warmcat.com>
> >wrote:
> >> >> >
> >> >> >>
> >> >> >>
> >> >> >> >
> >> >> >> >test at devpc:~/libwebsockets/build/bin$
> >./libwebsockets-test-client
> >> >> >> >127.0.0.1
> >> >> >> >--port=8888
> >> >> >>
> >> >> >> Turn up the logging with -d 1023 or so
> >> >> >>
> >> >> >> >libwebsockets test client
> >> >> >> >(C) Copyright 2010-2013 Andy Green <andy at warmcat.com> licensed
> >> >under
> >> >> >> >LGPL2.1
> >> >> >> >[1457:9886] NOTICE: Initial logging level 7
> >> >> >> >[1457:9886] NOTICE: Library version: 1.3 67f9459
> >> >> >> >[1457:9887] NOTICE: IPV6 compiled in and enabled
> >> >> >> >[1457:9887] NOTICE: libev support not compiled in
> >> >> >> >[1457:9889] NOTICE:  static allocation: 4472 + (12 x 1024 fds)
> >=
> >> >> >16760
> >> >> >> >bytes
> >> >> >> >[1457:9890] NOTICE:  canonical_hostname = pk-laptop
> >> >> >> >[1457:9890] NOTICE:  per-conn mem: 128 + 1594 headers +
> >protocol
> >> >rx
> >> >> >buf
> >> >> >> >Waiting for connect...
> >> >> >> >[1457:9932] WARN: problems parsing header
> >> >> >> >Exiting
> >> >> >> >[1457:9933] NOTICE: libwebsocket_context_destroy
> >> >> >> >
> >> >> >> >And on the node server, I see the following log
> >> >> >> >
> >> >> >> >test at devpc:~/node$ DEBUG=* node basic.js
> >> >> >> >   info  - socket.io started
> >> >> >> >   debug - destroying non-socket.io upgrade
> >> >> >> >   debug - destroying non-socket.io upgrade
> >> >> >>
> >> >> >> Is socket.io compliant with the actual websockets standard or
> >some
> >> >> >older
> >> >> >> RFC?
> >> >> >>
> >> >> >> It seems it can't parse our upgrade request (which does pretty
> >> >good
> >> >> >at
> >> >> >> being compliant with everything else).
> >> >> >>
> >> >> >> -Andy
> >> >> >>
> >> >> >>
> >> >>
> >> >>
> >>
> >>
>
>
>
>
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> http://ml.libwebsockets.org/mailman/listinfo/libwebsockets
>
>
>
> _______________________________________________
> Libwebsockets mailing list
> Libwebsockets at ml.libwebsockets.org
> http://ml.libwebsockets.org/mailman/listinfo/libwebsockets
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20140818/d66d43bf/attachment-0001.html>


More information about the Libwebsockets mailing list