Replies: 4 comments 1 reply
-
|
That's pretty much what the BroadcastingEchoServer.cpp is doing, yeah. Also, what the documentation says is "Many times people tend to attach user data which should belong to the websocket by putting the pointer and the user data in a std::map. That's wrong! Don't do that!" and "Going from user data to WebSocket is possible if you make your user data hold a pointer to WebSocket, and hook things up in the WebSocket open handler.", "[...] you could have the user data hold a pointer to some dynamically allocated memory [...] Sky is the limit here, you should never need any std::map for this." What I understand from this is: User data that belongs to the Websocket should not be in an std::map. Mapping the Websocket itself through to some internal ID should be okay through. Someone can correct me if I am wrong! |
Beta Was this translation helpful? Give feedback.
-
You can do whatever you want, but algorithmically speaking, it's going over the river to get water to attach an ID to the websocket and then lookup some user data in a separate map when you literally can have the reference / pointer to that user data straight up. It's log(N) lookup vs. O(1) where 1 is pretty much as small as you possibly can make it. |
Beta Was this translation helpful? Give feedback.
-
|
I mean the other way around, we are on the server and need to keep track of the connected client sockets. I.e. from the user data, we now need to go back to the websocket, possibly another client websocket. For example, we build the classic chat server, where Client 1 chats with Client 2. From the way I see it, storing a reference to Client 2 in Client 1's userdata might be little odd, but might be one way. |
Beta Was this translation helpful? Give feedback.
-
|
Use common sense |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
uWS is running it's own thread. What's the normal way to send a message to a specific client from outside uWS? My initial thought was a map from internal ID to socket pointer but the docs say that a map shouldn't be required. My current work around is to have each socket subscribe to it's internal ID as the topic, but this doesn't seem right.
Beta Was this translation helpful? Give feedback.
All reactions