Re: [Gtk-gnutella-devel] Two patches

[Steven W. <swi...@us...>]

Paul W Cassella wrote:
> 
> On Sat, 27 May 2000, Steven Wilcoxon wrote:
> 
> > Paul W Cassella wrote:
> 
> > > Steven Wilcoxon wrote:
> 
> > Actually the feature I was looking for would require everything to be
> > buffered to reduce the number of packets sent. The patch from the 19th
> > (which I had overlooked) would start getting complicated to implement
> > both together. I like the KISS principle. The two area of overhead I see
> > are the GSList for counting and the memcpy/memmove's.
> 
> The part where everything is written immediately is in fact doing the
> opposite of what you're trying to do.  If we haven't had partial writes to
> this host, it tries to send everything at once, instead of in 1024-byte
> pieces, like node_write will do.  This is more useful for high-bandwidth
> connections.
I agree. I'm not even looking for large amounts of buffering to gain
benefits. Even making sure that we write 128 or 230 byte minimums. Maybe
the optimal method is smaller writes get buffered and larger ones don't
(without flushing the buffers). A better understanding of the packets
being written, size, and frequence may be needed.

> > > > Feedback from anyone? Is this idea too simple to be true? What about the
> > > > timeout feature?
> 
> If you do this and it turns out that there is a significant performance
> benefit, it may be worthwile to try to wrap it up for use in a library.
As I suspected, in my configuration I don't detect a differenc. I'll
have to look into traffic monitor on my firewall to see if we can detect
improvements.

> > offset/sq_pos). If the entier buffer is not written, everything gets
> > slid forward. That means we should either count the packet as it's
> > buffered or memorize the length of each packet (and each time the buffer
> > is totally empty, make sure the GSList gets emptied also).
> 
> If I understand what you're saying, I think the following piece of code,
> from node_write:367, keeps that from happening.  It goes through the list
> of end-of-packets, and updates them.  When this loop finishes, each
> element of the list indicates how many more bytes need to be sent for each
> packet.
> 
> /* update the rest of the counts. */
> for(l = n->end_of_packets; l; l = l->next)
>   l->data = (gpointer) (((guint32) l->data) - r);
Yes it does, sorry for jumping to conclusions. How about changing the
comment to something like
	/* update the rest of the count locations */
or similar since it isn't updating the counts, but rather the location
where they will trigger.

> --
> Paul Cassella    ::  Doctor Who: He's back, and it's About Time.
> for...@cm... ::  http://www.contrib.andrew.cmu.edu/~pwc

S.W.