Bugzilla – Bug 130221
improvement ideas for drpmsync
Last modified: 2014-04-14 15:46:26 UTC
I did extensive tests with drpmsync the last days and found some bugs/problems/possible improvements: 1. drpmsync client selects a random version for the "have" parameter. This can lead to the case that the server sends the full package because he does not have a delta for this old version (any more) although the client could have provided a more recent version as well for which a delta would have been availlable on the server. In my opinion the client should always send the latest version with the "have" parameter to the server because it is most likely in that case to get a short delta file. Alternatively the protocol could be changed to allow multiple "have" parameters allowing the server to select the best. 2. It would be useful if the protocol had an option to only ask the server which patches would be availlable for a specific "have" case without actual transfer of the delta/rpm but instead transfer only the relative file name of the delta/rpm. This would allow a client to fetch the actual file from a faster server that does not speak drpmsync itself (like gwdg.de). An option could specify the external source as a URL. 3. An option to dump the fetched contents information to a file would be useful for debugging. Another option to reuse a dumped file instead of refetching this information for the server would even add more value when hacking at the tool because this reduces startup times of the tool dramatically. 4. Do you have a written documentation about the protocol (format of the requests and answer packages)? Currently I am reading all this information from the source but this is not very comfortable and specifying a protocol by written source code is error prone according accidential changes of the protocol and thus making incompatible versions of the protocol.
Thanks for playing with deltarpm! 1) the current development version already supports multiple "have" parameters. 2) Hmm, that's a bit difficult as there is no such thing as a relative filename. The server uses "combinedeltarpm" to combine multiple deltas into one, the resulting delta is not stored in the filesystem. 3) This is easy to implement. Note, however, that there is almost no startup time if the server's cache is up to date. 4) Not really, as it is work in progress. Basically the client sends standard HTTP requests, the answer is of the format: "DRPMSYNC" or "DRPMSYNK" for "keepalive" mode 4 bytes version in hex 4 bytes answer ID 8 bytes path len in hex 8 bytes answer block in hex path data answer block 32 bytes md5sum of answer block in hex answer block depends in the ID: GONE: file is gone FILE: file mode + mtime + file data FILZ: file mode + mtime + compressed file data RPM : file mode + mtime of resulting rpm (12 bytes) 8 bytes number of deltarpms in hex 8 bytes number of rpms in hex (always 0 or 1) number of deltarpms deltarpm info blocks: file mode + mtime (12 bytes) 32*3 bytes deltarpm name 8 bytes deltarpm size deltarpm data rpm data file mode is 4 bytes hex: TMMM T = 0: dir T = 1: file T = 2: symlink
1) Very good! 2) He could send all filenames of the uncombined files in that case. 3) drpmsync.opensuse.org never is because it is extremely overloaded. 4) Thanks.
Bump. Any of this still needs a fix?
1) is done. I don't know about drpmsync.opensuse.org. I think I'll close 2) with wontfix.