客户端/服务器之间同步文本的算法
用于同步客户端和服务器之间的文本文件（例如）的低延迟、低带宽算法是什么？
是否有一种设计，客户端发送其当前状态和服务器最后确认状态的增量？我正在考虑 Quake3 网络..
编辑 1：
更具体地说，diff/delta 算法在客户端/服务器环境中的行为如何。
例如，在客户端计算差异、发送到服务器、服务器解释并更新其存储、向客户端发送 ACK 是否更昂贵？或者采用客户端发送其完整状态并服务器存储它的复制模型是否更便宜？
编辑 2：
100 KB 文本文件。东西很小，不是太大。
What is a low-latency, low-bandwidth algorithm for synchronizing, say, a text file between a client and a server?
Is there a design where the client send a delta of it's current state and it's last ACK'd state from the server? I am thinking Quake3 networking..
EDIT 1:
More specifically, how would a diff/delta algorithm behave in a client/server environment.
e.g. Is it more expensive to calculate a diff on the client side, send to server, server interprets and updates its store, sends ACK to client? Or is it cheaper to have a replication model where client sends its full state and server stores it..?
EDIT 2:
100 KB text file. Something small, not too large.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
你的意思是像diff？
将文件的服务器端版本存储在客户端中。每当您需要同步时，请运行 diff（您可以自己编写或使用库）。然后将差异发送到服务器并让服务器修补它的本地版本。
You mean like a diff?
Store the server-side's version of the file in the client. Whenever you need to synchronize, run a diff (you can either write your own or use a library). Then send the difference over to the server and have the server patch it's local version.
如果客户端还编辑文本，并且具有撤消/重做功能，则撤消堆栈可用于增量。对于大文本和小更改，使用撤消堆栈应该比运行差异更有效。
If a client also edits text, and has an undo/redo feature then undo stack can be used for delta. For large texts and small changes using undo stack should be more efficient than running a diff.
对于文本，您可以使用 delta 算法，例如，查看 rsync 的工作原理。
Google采用了不同的方式来更新chrome，你可以“google”一下看看。
编辑：如果是一台服务器生成一项更改并在许多客户端中复制，则应该在服务器中完成。从问题的更改中，我了解到客户端（或许多客户端）将产生更改并希望将它们复制到服务器上。
嗯...我会考虑 4 件事：
太多客户端在服务器上发送和执行此操作：这几乎是 DoS
仅当客户端很少、服务器性能较高且客户端性能较低时，我才会在服务器上执行此操作。
否则，我只会对客户这样做。
For text you can use delta algorithm, take a look, for example, on how rsync works.
Google uses a different approach to update chrome, you can "google" it to see.
Edit: If it was a server generating one change and replicating in lots of clients, it should be done in server. From the question's changes, I understood that a client (or many clients) will produce the changes and want them to be replicated on server.
Well... I'd take in account 4 things:
Too many clients sending and doing that on server: it's almost a DoS
I'd only do that on server if there were few clients, high server performance and low client performance.
Otherwise, I'd only do that on clients.