Holly shit, that's a nasty one!
IMHO the only reliable solution to this kind of problems is to have a variation of Lamport Timestamps. This is how I would see it:
- Each client sends a random identifier during login (per channel).
- The server keeps a hash table with the identifiers and a 64 bit integer associated with each.
- The server purges this hash table once in a while so that it does not grow too large.
- The client has a 64 bit counter starting at 0.
- Before sending any message, the client increments the counter by 1.
- The client embeds the current counter value in every message.
- Every time the server receives a message from the client on a given channel it considers the counter.
- If the counter value in the message is lower than what the server has, it declares an error to the client.
- If the value is higher, the server performs the operation and associates the new counter value with the client id in its hash table.
This works because TCP guarantees ordering per connection. Recovery connections would be different TCP connections but would have the same client/channel ID.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub, or mute the thread.
{"api_version":"1.0","publisher":{"api_key":"05dde50f1d1a384dd78767c55493e4bb","name":"GitHub"},"entity":{"external_key":"github/xrootd/xrootd","title":"xrootd/xrootd","subtitle":"GitHub repository","main_image_url":"https://cloud.githubusercontent.com/assets/143418/17495839/a5054eac-5d88-11e6-95fc-7290892c7bb5.png","avatar_image_url":"https://cloud.githubusercontent.com/assets/143418/15842166/7c72db34-2c0b-11e6-9aed-b52498112777.png","action":{"name":"Open in GitHub","url":"https://github.com/xrootd/xrootd"}},"updates":{"snippets":[{"icon":"PERSON","message":"@ljanyst in #673: Holly shit, that's a nasty one!\r\n\r\nIMHO the only reliable solution to this kind of problems is to have a variation of Lamport Timestamps. This is how I would see it:\r\n\r\n1. Each client sends a random identifier during login (per channel).\r\n2. The server keeps a hash table with the identifiers and a 64 bit integer associated with each.\r\n3. The server purges this hash table once in a while so that it does not grow too large.\r\n4. The client has a 64 bit counter starting at 0.\r\n5. Before sending any message, the client increments the counter by 1.\r\n6. The client embeds the current counter value in every message.\r\n7. Every time the server receives a message from the client on a given channel it considers the counter.\r\n8. If the counter value in the message is lower than what the server has, it declares an error to the client.\r\n9. If the value is higher, the server performs the operation and associates the new counter value with the client id in its hash table.\r\n\r\nThis works because TCP guarantees ordering per connection. Recovery connections would be different TCP connections but would have the same client/channel ID."}],"action":{"name":"View Issue","url":"https://github.com/xrootd/xrootd/issues/673#issuecomment-374917529"}}}
Use REPLY-ALL to reply to list
To unsubscribe from the XROOTD-DEV list, click the following link:
https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1
