Cheetah: Keeping track of multiple connected clients

[bauss via Digitalmars-d-learn]

On Thursday, 18 May 2017 at 11:44:57 UTC, aberba wrote:
> On Tuesday, 16 May 2017 at 21:56:16 UTC, aberba wrote:
>> On Tuesday, 16 May 2017 at 17:49:07 UTC, bauss wrote:
>>> [...]
>>
>> It really awesome the way you responded quickly. About 
>> targeting a client, suppose I have clients A, B, and C.
>>
>> Message can be broadcast to all using above solution. But in 
>> case A want to sent message to B and not C, how does server 
>> detect the specific destination client's id? Does 
>> client.send(...) allow json string with target id from browser 
>> client?
>>
>> I'm trying to find a way to receive meesage in one language 
>> along with target client's id and send to the target after I 
>> have translated to another lang.
>
> To reframe my question, When client A sends a message meant for 
> client B, is there a facility in cheetah to identify source and 
> destination clients?
>
>  (looked through the code, did not find any obvious info on 
> properties of a client or a message event)

Well it isn't based directly around Websockets, so for those to 
work you'd have to implement the websocket protocol or you could 
attempt to fork cheetah and wrap vibe.d's websocket 
implementation into it; if you don't have time or don't really 
know how to exactly, then I'd see if I can make time for it. 
However as for identifying the source, it really depends on how 
your packet protocol. Cheetah isn't meant to be a one-type only 
socket library and it's up to the user themselves to implement 
their packet protocol because it can vary from implementation to 
implementation. Some might sent raw json, some might sent xml, 
some might sent raw binary, some might sent http packets, you get 
me? I might come up with a generic version to attempt to fit them 
all, but it's quite a bit of work to do so, which is why right 
now it's up to the individual user to implement their packet 
protocol. I'd assume since you're using Websockets your protocol 
is probably json. After the whole handshake for websockets are 
done then it should be fairly simple to implement the message 
receiving.

If you want to know how the exact implementation should be, then 
you can read here.

https://tools.ietf.org/html/rfc6455

I assume you'll be able to find what you're looking for there.

Reading it raw would be something like continuously receiving a 
static amount of byte like 1024 and then keep doing that until 
all chunks make up a proper json object, then you take the 
remaining bytes (Because they might hold next packet) and keep 
doing the same thing for the next object, then simply repeating. 
Then you can simply have a property in the object that has a 
client id (Which should correspond to the id the server has given 
the client.) As for how the client itself should know the id. You 
can simply send a packet to the client when it connects which 
contains the client id.

If you want the above simplified, let me know.