[Libwebsockets] Unable to communicate with node server over Websocket

sthustfo sthustfo at gmail.com
Mon Aug 18 18:05:59 CEST 2014


The id is delivered along with some timers and protocols in the body of the
HTTP response.



On Mon, Aug 18, 2014 at 9:10 PM, Andy Green <andy.green at linaro.org> wrote:

>
> On 18 Aug 2014 23:34, "sthustfo" <sthustfo at gmail.com> wrote:
> >
> > 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?
>
> How is the id delivered, ie, in a header?  Which header?  Something else?
>
> -Andy
>
> > 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/d77cc423/attachment-0001.html>


More information about the Libwebsockets mailing list