i know this one would be better of to the gdf but i dont bother to register with yahoo.

its also possible that something like this is already considered but the gdf is keeping their stuff closed so...

anyway, the current situation is that 80% of the traffic is queries. some gnutella clients can show the current bandwidth usage in kb. per node this is around 0.7kb/sec - 1.5kb/sec.

this number is misleading.

please take a look at
http://www.faqs.org/rfc/rfc791.txt
and
http://www.faqs.org/rfc/rfc793.txt

for a search request that has a 18 byte header and a 10byte search string you get around 40 bytes of overhead and thats not taking the lower level protocols into acount (PPP, TCP ACK`s..)

so i propose a new packet type that wraps several smaller query packets into one big packet.
packet example:

16 byte guid
1 byte function: some yet unused function
1 byte ttl: 0
1 byte hops: 0
4 byte payload: sum of sub packets size.

and then all the small query packets.

a modem user could handle a lot more queries when they are packed like this.

Nagle's algorithm:
http://www.faqs.org/rfc/rfc896.txt
I think everyone uses this.

i wont comment on your trust into the windows socket implementation

and the rfc you mentioned doesnt take multiple connections into account.
im getting around 6-10 packets/sec per node. lets just assume these are optimaly grouped into 4 packets and sent, it still would make more sense to send them once per second.

my basic idea was abstraction anyway so a host dont have to rely on the network stack.

A peer can already do this. All it takes is to buffer up several packets before doing a write to the socket (as was pointed out Nagle will do this already to a certain extent too). Output buffering is generally a good practice - it's also simpler and doesn't require changes to the protocol.

In general it's a bad idea for the application level protocol to make any assumptions about the lower level network protocol. There's no telling what the smallest MTU may be between you and another peer - packets may be fragmented, recombined or compressed at any point along the journey. Because of fragmentation, you might actually cause more packets to be sent.