In the first post related to the prototype server we didn’t have the chance to speak about security. To understand the security measures it is imprescindible to understand the client-server protocol and server-server protocol (federation). In this post we will talk about client-server protocol.
Client-server protocol is based on Operation Transformation ( OT ). If you are familiarized with data bases, when 2 users try to update the same data, they read the value at the same time and make their update to the server. At the end, we loose one of this updates. To prevent this kind of inconsistency, data bases use the transaction. In a few words, when somebody use one piece of data, this data is locked and if someone else wants to use, they have to wait until the first finish. This is a good solution for example bank accounts, they can’t afford lose any kind of data. But, if we want to develop real time edition, this is not an option. OT allows users editting in parallel and send their updates in real time. The basic theory of OT is allow client send data as fast as they can, and server too.
Basic OT schema
As we see, users send operation at the same time from the same source (abc). O1 inserts X in position 0 and O2 deletes position 2 “c”. Server receives 2 operations, at the same time. If we change first O1 and later O2, the result is different as we want (xabc + del[2] = xac). For this reason it is necessary to have a order tag. Order tag is only a time reference used to order every operation in message stream. What server do is to apply user operations and broadcast to other users. Server has to know the position in time of each operation and make the changes properly. This is the basic view of howOT works. In Wave OT has the peculiarity that users can’t send data as fast as they can. If this it is allowed, each user has to have space state with each server, this means an intensive memory usage and this complicates the server algorithm by requiring it to convert clients’ operations between state spaces. What Wave OT does, is to send operations and wait the acknowledgment from the server. This little change make the server has to have only one space state composed of the operation history. What clients has to do is cache all the operations until get the ack from the server. The little problem is that clients will see the other users operations in intervals of approximately 1 round trip time. This will be not a problem if the round trip time is short, otherwise, changes will take a while.
Once we understand Wave OT, we can talk about client-server protocol. Operations are mutations on wavelets. We can understand the wavelet state as the sequence of operations that have affected him. What client and server does is to exchange modifications to a wavelet. Server is the responsible to broadcast the operations to all users involved in that wavelet ( in the most cases all the participants of the wave, in private messages only the participants of the private message ). Users apply modifications received from the server to their own copy of the wavelet. All the users must apply operations identically to maintain a consitent state between all users.
Wave OT requires that all the operations must be ordered, as we said, in Wave OT the client has to wait for the ACK from the server, and then send the new operations. The user is the responsible of ordering the new operations and that order must accord the version number provided by the server. A participant that has a wavelet “open” would mean is actively exchanging operations concerning to that wavelet. To open a wavelet, the clientsends an Open Request (Wave ID and Wavelet ID). The server responds with the serialized state of the wavelet and history hash at that version. This is necessary to order new operations and get the data in the wavelet.
In a normal communication, client sends Delta (Sequence of one or more operations) and Version Number. Server acknowledges sending the new version and the History hash. Server can send changes made by other users, in this case server sends Delta, version number and history hash. In a failed client-server communication, client and server have to agree on a common state of the wavelet upon reconnecting. The client reopens the wavelet, sending a list of history hashes previously received from the server. Client sends: Wave ID, Wavelet ID, list of history hashes known to the client. Server responds last known history hash selected from the list of the history hashes sent by the client, most recent history hash on the wavelet and a sequence of deltas. If history hashes are equal, user and server are synch. If history hashes doesn’t match or server does not recognize any of the client-provided hashes, client and server have failed to agree on a common state of the wavelet, client must reload the wave to get new common state. This is the reason of the error prompted in Google Wave that ask for reload page.
client-server data diagram
Today Google Wave Federation Prototype Server doesn’t have certificate security between user and server. Clients trust their service providers (wave server) to correctly handle their data. Google staff expect that one day user signature will be supported. We think this will be completely necessary if Wave goes into companies.
This is all for the fist part, in the second part we will talk about server-server protocol and their security.
Stay on the top of the wave!
Tags: ack, client server protocol, client-server, hash tree, OT, protocol client, schema, wave ot, wavelet
If you like what you see, please, support us:
Posts that may be of your interest:
- Understanding Wave protocol – Part II
- Google Wave Federation protocol updates
- Wave Federation
- Wave Federation Prototype Server
- Access Control in Wave
Understanding Wave protocol – Part I
In the first post related to the prototype server we didn’t have the chance to speak about security. To understand the security measures it is imprescindible to understand the client-server protocol and server-server protocol (federation). In this post we will talk about client-server protocol.
Client-server protocol is based on Operation Transformation ( OT ). If you are familiarized with data bases, when 2 users try to update the same data, they read the value at the same time and make their update to the server. At the end, we loose one of this updates. To prevent this kind of inconsistency, data bases use the transaction. In a few words, when somebody use one piece of data, this data is locked and if someone else wants to use, they have to wait until the first finish. This is a good solution for example bank accounts, they can’t afford lose any kind of data. But, if we want to develop real time edition, this is not an option. OT allows users editting in parallel and send their updates in real time. The basic theory of OT is allow client send data as fast as they can, and server too.
Basic OT schema
As we see, users send operation at the same time from the same source (abc). O1 inserts X in position 0 and O2 deletes position 2 “c”. Server receives 2 operations, at the same time. If we change first O1 and later O2, the result is different as we want (xabc + del[2] = xac). For this reason it is necessary to have a order tag. Order tag is only a time reference used to order every operation in message stream. What server do is to apply user operations and broadcast to other users. Server has to know the position in time of each operation and make the changes properly. This is the basic view of howOT works. In Wave OT has the peculiarity that users can’t send data as fast as they can. If this it is allowed, each user has to have space state with each server, this means an intensive memory usage and this complicates the server algorithm by requiring it to convert clients’ operations between state spaces. What Wave OT does, is to send operations and wait the acknowledgment from the server. This little change make the server has to have only one space state composed of the operation history. What clients has to do is cache all the operations until get the ack from the server. The little problem is that clients will see the other users operations in intervals of approximately 1 round trip time. This will be not a problem if the round trip time is short, otherwise, changes will take a while.
Once we understand Wave OT, we can talk about client-server protocol. Operations are mutations on wavelets. We can understand the wavelet state as the sequence of operations that have affected him. What client and server does is to exchange modifications to a wavelet. Server is the responsible to broadcast the operations to all users involved in that wavelet ( in the most cases all the participants of the wave, in private messages only the participants of the private message ). Users apply modifications received from the server to their own copy of the wavelet. All the users must apply operations identically to maintain a consitent state between all users.
Wave OT requires that all the operations must be ordered, as we said, in Wave OT the client has to wait for the ACK from the server, and then send the new operations. The user is the responsible of ordering the new operations and that order must accord the version number provided by the server. A participant that has a wavelet “open” would mean is actively exchanging operations concerning to that wavelet. To open a wavelet, the clientsends an Open Request (Wave ID and Wavelet ID). The server responds with the serialized state of the wavelet and history hash at that version. This is necessary to order new operations and get the data in the wavelet.
In a normal communication, client sends Delta (Sequence of one or more operations) and Version Number. Server acknowledges sending the new version and the History hash. Server can send changes made by other users, in this case server sends Delta, version number and history hash. In a failed client-server communication, client and server have to agree on a common state of the wavelet upon reconnecting. The client reopens the wavelet, sending a list of history hashes previously received from the server. Client sends: Wave ID, Wavelet ID, list of history hashes known to the client. Server responds last known history hash selected from the list of the history hashes sent by the client, most recent history hash on the wavelet and a sequence of deltas. If history hashes are equal, user and server are synch. If history hashes doesn’t match or server does not recognize any of the client-provided hashes, client and server have failed to agree on a common state of the wavelet, client must reload the wave to get new common state. This is the reason of the error prompted in Google Wave that ask for reload page.
client-server data diagram
Today Google Wave Federation Prototype Server doesn’t have certificate security between user and server. Clients trust their service providers (wave server) to correctly handle their data. Google staff expect that one day user signature will be supported. We think this will be completely necessary if Wave goes into companies.
This is all for the fist part, in the second part we will talk about server-server protocol and their security.
Stay on the top of the wave!
Tags: ack, client server protocol, client-server, hash tree, OT, protocol client, schema, wave ot, wavelet
If you like what you see, please, support us:
Posts that may be of your interest: