Wayne, I've been ruminating a bit on the qsorted flist and duplicate removal and have an idea. What if we removed end_file_entry() from send_file_name() and instead had a for(i=0; i < flist->count; ++i) send_file_entry(flist->files[i], f, ??) in send_file_list(). As near as i can tell this would be unnoticeable to the protocol. Once done the sort of the file list could be moved to precede sending it. Thus making the sort on the receiver a one-pass noop that could be dropped after a protocol bump. It would also improve slightly the effectiveness of the SAME_NAME optimisation. With the protocol version dependant receiver non-sort the sort order can be adjusted as necessary to produce whatever effects are wanted in the way of duplicate removal. Just a thought. -- ________________________________________________________________ J.W. Schultz Pegasystems Technologies email address: jw@pegasys.ws Remember Cernan and Schmitt
On Fri, May 16, 2003 at 05:29:24PM -0700, jw schultz wrote:> With the protocol version dependant receiver non-sort the > sort order can be adjusted as necessary to produce whatever > effects are wanted in the way of duplicate removal.Yes, that sounds like a very promising idea. As long as there's not some hidden gotcha, getting rid of the sort on the receiver side makes the protocol more optimal and more flexible. Something we should definitely look into. ..wayne..
Seemingly Similar Threads
- [Bug 1959] New: writefd_unbuffered failed to write 4092 bytes phase send_file_entry broken pipe
- (no subject)
- DO NOT REPLY [Bug 3979] New: writefd_unbuffered failed to write 4092 bytes phase send_file_entry broken pipe
- HFS+ resource forks: WIP patch included
- [Bug 8053] New: Older C compilers don't allow in-line declarations flist.c:1653