[Libwebsockets] How to get socket id from incoming request ?

Meir Yanovich meiry242 at gmail.com
Mon Jun 13 05:39:30 CEST 2016


Thanks Bruce ,

On Mon, Jun 13, 2016 at 3:31 AM, Bruce Perens <bruce at perens.com> wrote:

> Meir, libwebsockets connects to the socket provided by the new Javascript
> WebSocketI() API. socket.io may use this API when it's available, but it
> does something else on older browsers that isn't compatible with
> libwebsocket.
> socket.io has a "room" functionality for broadcast messages using the ID,
> but there is nothing in libwebsockets for that function.
>
> On Sun, Jun 12, 2016 at 3:23 AM, Andy Green <andy at warmcat.com> wrote:
>
>>
>>
>> On June 12, 2016 5:29:16 PM GMT+08:00, Meir Yanovich <meiry242 at gmail.com>
>> wrote:
>> >I try this as Andy suggested all of this in the server . under the case
>> >LWS_CALLBACK_RECEIVE:
>> >
>> >long wsi_adress = &wsi;
>> >lwsl_notice("string recived from client:%lu\n", wsi_adress);
>> >
>> >i tried to invoke several ws requests  from different browsers
>> >but it always gave me the same value . am i do it currently of you
>> >meant to
>> >something totally different ?
>>
>> No two active connections will have the same wsi value at the same
>> time.... for sure.  Two sequential connections might do.  Two sequential
>> connections (like connect 1; close 1; connect 2; close 2) from the same IP
>> could conceivably also use the same local and remote ports, and re-use the
>> same wsi address.  So the only sure way to get a unique number would be
>> increment an ordinal on the server side at each ESTABLISH, like 'I'm
>> connection 0', then the next 'I'm connection 1'.  Then they're going to be
>> unique (until the number rolls over, which would take a long time).
>>
>> But to maintain your map you also must delete mappings when the
>> connection closes.  Otherwise it'll just grow until it used all the memory,
>> right?  So your complaint before, 'I don't want to track wsi lifecycle'
>> doesn't seem to make sense.
>>
>> And why would socket.io care if you reuse the same connection id, if
>> everyone agreed the first guy using it had his connection closed and is
>> destroyed now?  Then no problem using the wsi number.
>>
>> You're going around in circles because you have not explained the
>> requirements for this id number from socket.io perspective, and you're
>> asking on a completely unrelated list, so it's a matter of luck if anyone
>> reading this list happens to know (I have no experience with it).
>>
>> You should stop asking here for now and go and make sure you understand
>> the requirements for the id yourself (by looking at other socket.io
>> implementation sources or asking guys on that project).  Then come back and
>> ask for exactly what you need if it's still mysterious by then.
>>
>> -Andy
>>
>> >On Sun, Jun 12, 2016 at 12:28 PM, Meir Yanovich <meiry242 at gmail.com>
>> >wrote:
>> >
>> >> I try this as Andy suggested all of this in the server . under the
>> >case
>> >> LWS_CALLBACK_RECEIVE:
>> >>
>> >> long wsi_adress = &wsi;
>> >> lwsl_notice("string recived from client:%lu\n", wsi_adress);
>> >>
>> >> i tried to invoke several ws requests  from different browsers
>> >> but it always gave me the same value . am i do it currently of you
>> >meant
>> >> to something totally different ?
>> >>
>> >> On Sun, Jun 12, 2016 at 11:37 AM, Meir Yanovich <meiry242 at gmail.com>
>> >> wrote:
>> >>
>> >>> Yes it is server side
>> >>> You mean the wsi pointer long ?
>> >>> Or what ?
>> >>>
>> >>>
>> >>>
>> >>> ‫ב-12 ביוני 2016, בשעה 10:52, ‏‏Andy Green ‏<andy at warmcat.com>
>> >כתב/ה:‬
>> >>>
>> >>>
>> >>>
>> >>> On June 12, 2016 3:23:19 PM GMT+08:00, Meir Yanovich
>> ><meiry242 at gmail.com>
>> >>> wrote:
>> >>>
>> >>> Yes this is the case i want it to be lookup key .
>> >>>
>> >>>
>> >>> If we're talking about the server, the port the socket is connected
>> >to on
>> >>> the server side will uniquely identify it, at least while the
>> >connection is
>> >>> connected.
>> >>>
>> >>> But the wsi will also do that... again while it's connected.
>> >>>
>> >>> Or just increment a magic static index every ESTABLISHED callback
>> >and tag
>> >>> the per-connection struct with that.  But if that's all then your
>> >map will
>> >>> only grow.
>> >>>
>> >>> So IIUI you have no choice but track the connection lifecycle, if
>> >the
>> >>> type of the id is 'long' then wsi is as good as anything.
>> >>>
>> >>> -Andy
>> >>>
>> >>> On Sun, Jun 12, 2016 at 10:01 AM, Edwin van den Oetelaar <
>> >>>
>> >>> oetelaar.automatisering at gmail.com> wrote:
>> >>>
>> >>>
>> >>> On Sun, Jun 12, 2016 at 8:12 AM, Meir Yanovich <meiry242 at gmail.com>
>> >>>
>> >>> wrote:
>> >>>
>> >>>
>> >>> I want to keep it as key in hash map
>> >>>
>> >>>
>> >>>
>> >>> (hash map is implementation detail)
>> >>>
>> >>>
>> >>> So solve what problem?
>> >>>
>> >>> To find the lookup up later and use the connection for a reply
>> >maybe?
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> ‫ב-12 ביוני 2016, בשעה 06:18, ‏‏Bruce Perens ‏<bruce at perens.com>
>> >>>
>> >>> כתב/ה:‬
>> >>>
>> >>>
>> >>>
>> >>>
>> >>> On Sat, Jun 11, 2016 at 2:33 PM, Andy Green <andy at warmcat.com>
>> >>>
>> >>> wrote:
>> >>>
>> >>>
>> >>>
>> >>> Why are you asking on the lws list about some socket.io-specific
>> >>>
>> >>> detail?
>> >>>
>> >>>
>> >>>
>> >>> Just say what you want to do with it, once you have it, and we can
>> >>>
>> >>> probably give you a portable way. :-)
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>>
>> >>> Libwebsockets mailing list
>> >>>
>> >>> Libwebsockets at ml.libwebsockets.org
>> >>>
>> >>> http://libwebsockets.org/mailman/listinfo/libwebsockets
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >>>
>> >------------------------------------------------------------------------
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>>
>> >>> Libwebsockets mailing list
>> >>>
>> >>> Libwebsockets at ml.libwebsockets.org
>> >>>
>> >>> http://libwebsockets.org/mailman/listinfo/libwebsockets
>> >>>
>> >>>
>> >>>
>> >>
>> >
>> >
>> >------------------------------------------------------------------------
>> >
>> >_______________________________________________
>> >Libwebsockets mailing list
>> >Libwebsockets at ml.libwebsockets.org
>> >http://libwebsockets.org/mailman/listinfo/libwebsockets
>>
>> _______________________________________________
>> Libwebsockets mailing list
>> Libwebsockets at ml.libwebsockets.org
>> http://libwebsockets.org/mailman/listinfo/libwebsockets
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://libwebsockets.org/pipermail/libwebsockets/attachments/20160613/2c328e7c/attachment-0001.html>


More information about the Libwebsockets mailing list