emberry-org / emberry

🍊 A new way to chat with Friends
GNU General Public License v3.0
13 stars 1 forks source link

frontend skips messages #23

Open devensiv opened 2 years ago

devensiv commented 2 years ago

There is a race condition while opening a room. There might be messages received from the peer before the front-end starts "listening" for the the message_received event causing the message to never arrive in the front-end

I have 2 possible solutions for that in mind:

1. Ping-Pong-Peng

front-end implementation of something similar to the P3 maneuver that we use in hole-punching -> this requires 2-3 messages to be sent by both either side of the conversation (best case 4 messages in total, worst case 5 messages in total)

2. more events

front-end sends an event to the back-end to let it know that it can now emit messages_received events -> to do this properly this requires caching messages in the back-end

3. Dirty Solution

The dirty solution would be to add a delay before we start to send messages after opening a room. -> for sensible delays this just makes the occurrence less likely and does not solve the core problem -> this is the least work

mxcop commented 2 years ago

There is one more solution:

4. Receive all messages through one event

Instead of having a seperate event for each chat room. We can just have one on_message event which contains both the message and a room id. And honestly I highly doubt a single event channel will ever be bottlenecked by messages.

devensiv commented 2 years ago
  1. version 2: Only start the holepunching once the frontend is ready. This ensures that no messages are sent before the frontend is loaded -> slows down establishing the connection -> relatively easily implemented, no caching required
devensiv commented 1 year ago

How about we scrap all the previous ideas and just open the frontend room UI and subscribe to the message event before the room has been established: From the requesting client side: we would open the room UI at request time (and simply close it or hide it again when the request was rejected) From the receiving client side: we open the room UI as soon as we get the request and close if needed (when we reject the attempt)