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.
