Possible to stop message playback to sender?

[Igor Clark]

Hi there,

If I set "push_stream_websocket_allow_publish on;" in a given channel, is it possible to switch off message echoes to senders, so that each client only receives messages sent by other clients in the same channel?

Thanks!

Igor

[Wandenberg Peixoto]

Hi Igor,

currently this is not supported.

For compatibility is the same behavior that when the client publish a message using POST.

Regards,

Wandenberg

--
You received this message because you are subscribed to the Google Groups "nginxpushstream" group.
To unsubscribe from this group and stop receiving emails from it, send an email to nginxpushstre...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Igor Clark]

Hi Wandenberg!

Thanks for the info.

I'm hoping to avoid making POST requests as there will be quite a lot of back-and-forth from clients, and I'd like to keep it happening in a single websocket connection if possible. Is it not supported because of architectural reasons, for example the dispatcher doesn't know which client a message came from, or is it something that I might be able to patch reasonably straightforwardly? If it's patchable, I wonder if you could let me know roughly where in the code to start looking?

Thanks again,
Igor

[Wandenberg Peixoto]

Hi Igor!

I only mentioned the POST to "justify" the module behavior.

Will be much better for your application use the websocket connection, you are right.

The dispatcher doesn't know who published the message.

If you send a POST or send it through websocket it is appended to the channel and than an alert is sent to dispatcher.

To keep track of which user sent the message we will need to spent a little bit more memory and spent some time comparing on the dispatcher. This time is very low concerning the number of users, but can increase a lot depending of your setup.

There is a specific reason for not receive the message you have sent despite of the bandwidth/latency? 

Another problem related is concurrency, you can "receive" the messages in a different order than another client.

[Igor Clark]

Ah, I see what you mean about the POST. Understood.

The other part makes sense too, thanks for explaining. I was hoping to avoid receiving the extra messages because clients are likely to be on mobile and I wanted to keep the communication overhead as low as possible. Also it means we'd need to implement some kind of identifier in the messages, with each client testing whether it's an "incoming" or "echoed outgoing" message - it'd be less work for them to do if they just didn't receive the message. But it's not a huge overhead, we'd just have to keep the message format as terse as possible.

Regarding the message order, is that a general rule? Our application will have many channels but with only two clients connected to each channel. Will clients in the same channel might get messages in different orders?

Thanks :-)

[Wandenberg Peixoto]

Once the message is on the channel the order is guaranteed to be the same to all clients.

I imagine that you are constructing something like a private chat, so the clients probably will be on the same server and you shouldn't have a problem with that.

The "out of order" I mentioned that would happens if you do not receive the message that you have just sent is in the way of if the user_1 publish a message "on the same time" as the user_2, for the point of view of user_2 it publish the message first, and when receive the message from user_1 will be like M2 -> M1, and for the user_1 will be the opposite.
Since you receive the message that you have sent, the order is guaranteed to be the same for both users.

You have to pay attention if your users can be on different servers, since you have to replicate the message to the other server.

We don't have the cluster solution built in yet :(

[Igor Clark]

Ah I see. OK that all makes sense. Thank you!

A chat is a good guess - it's actually a game, and they will indeed be on the same machine, so it should be fine. If it goes ahead we plan to have a secondary mechanism which connects up players and hands out URLs to each, to make sure they're on the same server. It'll be boxed in to specific geo areas so that shouldn't be a huge problem.

Is there a plan for a cluster solution in the module? That would be pretty amazing!

Thanks for taking the time to explain :-D