Menu
▾
▴
#1 MSETDocClient's I/O Queuing
MSETDocClient's setApplyingRemotes and setSendingLocals
both don't always take immediate effect. Most times
inboundQ.blockingRemove and outboundQ.blockingRemove
are blocked on an empty queues when sending and
receiving are paused so when one comes in the queue it
is processed before the pause takes effect.
Logged In: YES
user_id=479347
Simply put, it always does one last receive or one last send
before it starts queuing b/c the queues are blocked when
told to start.
Logged In: YES
user_id=479347
ALERT: need to create a seperate settingStateQ that collects
all the inbound edits until all the state edits are in the
inboundQ then dequeues all the edits from the settingStateQ
on to the inboundQ. This should allow us to only only need
to check for duplicates during this process and not on every
received remote edit.
ALERT: ideally resetState method should NOT be necessary
ALERT: When should we start queuing inbound edits for late
joiners?
a) as soon as they connect
b) as soon as they accept a designated state sender
c) as soon as they receive the state for now going with a)
ALERT: What if queuingIn/Out is on, can you send your state?
I don't think so b/c even if you only send the edits that
are not queued, the receiving user my never receive those
edits that were queued by the state sender before the late
joiner connected. But if we don't allow this then what
happens if all users are queuing edits?
ANSWER: Those queing outbound are still candidates for state
sending b/c the state requester will receive those edits
when they are sent. Those that do not have an empty inbound
queue are bad candidates though. The reason is the state
requester will never receive the edits in the inbound queue.
We currently send only edits that have been applied to the
mset which does not include queued inbounds. This leads back
to the problem of requesting the state when all users
have queued inbounds. Currently the only solution i see to
this is to also send the queued inbounds but this might have
flaws too.
Logged In: YES
user_id=479347
Another problem is requesting the state.
The current procedure is as follows:
1. new user joins
2. all existing users send the new user a state offer
3. new user accepts the first offer and stops accepting offers
4. new user sends for the accepted user's state
The main problem is the lack of a message delivery
guarantee. We need a fail safe for warning the user that
they need to try to reconnect in the cases where a
disconnect could leave the new user endlessly waiting for a
response.