[Libwebsockets] Problem with using multiple sub-protocols

Andy Green andy.green at linaro.org
Fri Jul 3 08:41:24 CEST 2015


On 3 July 2015 at 14:26, sunny s <sunny46916 at gmail.com> wrote:
> Hello Brice and Roger,
>
> Thank you for your responses.
>
> The way Brice have placed "bsws-protocol" declaration at 0th index of
> 'protocols' array, similarly we have put our own protocol at 0th
> index and it works fine too.
>
> However, problem is when we want to use multiple ports in a single
> application. e.g. Earlier we had our single threaded firmware
> communicating with 3 different entities over 3 different TCP ports:
> 1000, 1001 and 1002. Now we want to use websocket instead of TCP.
>
> We believe that it's not possible to use multiple ports with websocket.
> So if all 3 entities want to communicate with our firmware then we
> need some mechanism to differentiate which one is talking now.
> Hence we thought, we will use 3 different protocols. However, as
> discussed earlier, we found that the only callback that gets called
> is the one declared for protocol from 0th index of 'protocols' array.
>
> Is it not possible to use multiple ports with websocket?

Yeah it should be.

Client and server are quite different cases and you need to be clear
what you are doing.

Three client connections from your app to three servers should be
trivial.  You would use different protocols only if they're carrying
different kinds of data.

One port serving three ws protocols should also be trivial.  Just list
them as in the server test app.

Three different servers in your app on three different ports should
also be doable, but it means three different *context* structs, don't
re-use the context structs but make three of them.  You can point
multiple protocol callbacks to the same callback handler even if it
has a different context.

> Is it not possible to use multiple sub-protocols with websocket?
> If yes, then how can we get multiple protocols working
> (respective callback hits)?

Just look at the test apps you can see that question is not your
problem.  The test client and server use 2 x protocols on one socket
and that works, right?

-Andy

> Regards,
> Sunny
>
>
>
>
> On 1 July 2015 at 21:03, Brice Hamon <brice at ydotm.com> wrote:
>>
>> I have created a simple client to test my server.
>> I use my own protocol also, but don't use the HTTP one.
>>
>> I got the client to work by doing this:
>>
>> //
>> ----------------------------------------------------------------------------
>> /* list of supported protocols and callbacks */
>> static struct libwebsocket_protocols protocols[] =
>> {
>> #if 0
>>     // first protocol must always be HTTP handler
>>     {
>>             "http-only",            // name
>>             callback_http,          // callback
>>             0,                      // per_session_data_size
>>             0,                      // max frame size / rx buffer
>>             0,                      // the lib deal with partial tx
>>             // filled in on server init but gcc not happy
>>             NULL,
>>             0,
>>             0,
>>     },
>> #endif
>>     {
>>             "bsws-protocol",
>>             callback_bsws,
>>             sizeof(struct per_session_data_bsws),
>>             1024*100,
>>             0,
>>             // filled in on server init but gcc not happy
>>             NULL,
>>             0,
>>             0,
>>     },
>>     {
>>             NULL, NULL,     /* End of list */
>>             0,
>>             0,
>>             0,
>>             // filled in on server init but gcc not happy
>>             NULL,
>>             0,
>>             1,
>>     }
>> };
>>
>> Then I create my context the connect.
>>
>> No issues.
>>
>> On Wed, Jul 1, 2015 at 11:22 AM, Roger Light <andy.green at linaro.org>
>> wrote:
>>>
>>> Hi Sunny,
>>>
>>> I wasn't reading carefully enough, I'd not spotted that you were
>>> creating a client. I'm afraid I've done zero client work with
>>> libwebsockets so can't really comment.
>>>
>>> I would suggest using your code with something known working though -
>>> the libwebsockets test servers for example.
>>>
>>> Cheers,
>>>
>>> Roger
>>>
>>>
>>>
>>> On Wed, Jul 1, 2015 at 3:30 PM, sunny s <sunny46916 at gmail.com> wrote:
>>> > Hello Roger,
>>> >
>>> > Thank you so much for the quick reply.
>>> >
>>> > We had tried keeping "http" at 0th index and dumb-increment-protocol
>>> > at 1st index in "protocols" structure in our client application.
>>> > However, it didn't work.
>>> >
>>> > Please find related code snippet below:
>>> > ====================================================================
>>> > static struct libwebsocket_protocols protocols[] = {
>>> > {
>>> > "http-only",
>>> > callback_http,
>>> > 0
>>> > },
>>> > {
>>> > "dumb-increment-protocol",
>>> > callback_dumb_increment,
>>> > 0
>>> > },
>>> > {
>>> > NULL, NULL, 0
>>> > }
>>> > };
>>> >
>>> > //-------------------------------------------------------------------
>>> > int main(void)
>>> > {
>>> > .......
>>> > .......
>>> >
>>> > context = libwebsocket_create_context(&info);
>>> > /* Note:172.16.10.160 is a server IP
>>> > * Chat is server(C# .NET) service to which client wants to
>>> > * connect. */
>>> >
>>> > client = libwebsocket_client_connect(context,"172.16.10.160",4649,
>>> > 0, "/Chat",
>>> > "172.16.10.160",
>>> > "172.16.10.160",
>>> > protocols[0].name,
>>> > -1);
>>> > while (n>=0)
>>> > n=libwebsocket_service(context,1000);
>>> > }
>>> >
>>> > //-------------------------------------------------------------------
>>> > static int callback_http(struct libwebsocket_context *context,
>>> > struct libwebsocket *wsi,
>>> > enum libwebsocket_callback_reasons reason,
>>> > void *user,void *in, size_t len)
>>> > {
>>> >   return 0;
>>> > }
>>> >
>>> > //-------------------------------------------------------------------
>>> > static int callback_dumb_increment(struct libwebsocket_context
>>> > *context,
>>> > struct libwebsocket *wsi,
>>> > enum libwebsocket_callback_reasons reason,
>>> > void *user,void *in, size_t len)
>>> > {
>>> > switch (reason)
>>> > {
>>> > case LWS_CALLBACK_CLIENT_ESTABLISHED:
>>> > {
>>> > printf("CONNCETION WITH SERVER ESTABLISHED....\n");
>>> > libwebsocket_callback_on_writable(context,wsi);
>>> > break;
>>> > }
>>> > case LWS_CALLBACK_CLOSED:
>>> > {
>>> > printf(" LWS CALLBACL CLOSED..\n");
>>> > break;
>>> > }
>>> > case LWS_CALLBACK_CLIENT_RECEIVE:
>>> > {
>>> > printf("RECEIVED DATA FROM SERVER:%s\n",(char*)in);
>>> > break;
>>> > }
>>> > case LWS_CALLBACK_CLIENT_WRITEABLE:
>>> > {
>>> > char data[100]="Hello";
>>> > int i=0;
>>> > unsigned char *buff =
>>> > (unsigned char*) malloc (LWS_SEND_BUFFER_PRE_PADDING
>>> > + strlen(data)
>>> > + LWS_SEND_BUFFER_POST_PADDING);
>>> > for(i=0;i<strlen(data);i++)
>>> > buff[LWS_SEND_BUFFER_PRE_PADDING+i]= data[i];
>>> > libwebsocket_write (wsi,&buff[LWS_SEND_BUFFER_PRE_PADDING],
>>> > strlen(data), LWS_WRITE_TEXT);
>>> > free(buff);
>>> > break;
>>> > }
>>> > default:
>>> > printf("unhandled callback\n");
>>> > break;
>>> > }
>>> > return 0;
>>> > }
>>> > ====================================================================
>>> >
>>> > observations:
>>> >
>>> > 1. In client application, after context is created successfully, if
>>> > we use "protocol[1].name" in API call libwebsocket_client_connect()
>>> > then HTTP request & response comes properly. Protocol also switches
>>> > over to websocket but callback “dumb-increment-protocol” does not get
>>> > called. Only “callback_http” gets called.
>>> >
>>> > 2. If we keep dumb-increment-protocol at 0th index of "protocols"
>>> > structure and then try to connect by using "protocol[0].name" then in
>>> > libwebsocket_client_connect() API call, protocol switches over to
>>> > websocket. Callback “dumb-increment-protocol” gets called properly and
>>> > client server communication works successfully.
>>> >
>>> > Are we missing anything in protocols declaration or usage?
>>> >
>>> > Regards,
>>> > Sunny
>>> >
>>> >
>>> _______________________________________________
>>> Libwebsockets mailing list
>>> Libwebsockets at ml.libwebsockets.org
>>> http://ml.libwebsockets.org/mailman/listinfo/libwebsockets
>>
>>
>



More information about the Libwebsockets mailing list