Hi, On Oct 16, 3:04 pm, tobber harley <[email protected]> wrote: > Hey Wave Gurus,
I am not a wave guru but working on a client as well ... > > 1) How to detect the server acknowledge? Should I compare the > HashedVersion from my local wavelet and from the received delta [src: > deltaAndVersion.second] (is that the HistoryHash from the Client- > Server Protocol whitepaper?) , if the hashes are equal and the version > from the received delta is higher than my local version, the operation > is acknowledged? Or I am wrong? I can only judge by the proto files I found. But it seems to me (just an educated guess) that you send a ProtocolSubmitRequest and you get back a ProtocolSubmitResponse. This is perhaps the ack you are waiting for. Or it is only the ack from your local wave server and not the ack from the remote wave server. Hard to tell ... I logged the TCP connection of the FedOne console client. My problem is still that I get a ProtocolWaveletUpdate for the delta that the client submitted. When comparing with the Jupiter paper I do not understand why. Why does the server send me the transformed delta that I submitted? This is IMHO not the case in Jupiter. > 2) I work in my client with three threads: > - event-dispatch-thread (swing): apply the operation to my local > document and add it to a queue (FIFO). > - consumer thread: take the operation from the queue and send it > to the server, then wait for the acknowledge > - receiver thread: its the (network) thread where the > "receiveWaveletUpdate" method runs. Here I filter the acknowledge and > tell my consumer thread to send the next operation or (if its not a > acknowledge) transform the incoming operation against the queue and > apply the operation to the local wavelet. Is that the right way? I think that's correct. However, I do not see why we need to filter for the ack anyway. > 3) It is very hard for me to synchronize these threads. I think the > receiver thread has the highest priority, because the operations which > the consumer threads sends, has to be on the server´s OT path. What > happens when the consumer thread sends a operation, and receiver > thread gets asynchronously at same moment a operation, I think my > transmitted message wouldn´t be on the server´s OT path? It is on the server's path. Read the jupiter paper carefully. They describe an invariant which applies to your scenario. When you send a message to the server, then this is the only message from you which the server did not yet ack. Thus, your client state is a past server state plus your new client message. By definition this client message is on the server's OT path. Greetings Torben > > Maybe all of this is totally wrong. It would be so great, if someone > could give me some tips, or just say yes or no to my points. > > Thanks! > tobber --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Wave Protocol" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/wave-protocol?hl=en -~----------~----~----~----~------~----~------~--~---
