> The problem is that throughput and responsiveness are enemies. no. not throughput, but buffer sizes are the enemy of latency
> you're trying to push a large quantity of data down a TCP connection, > and try to do anything interactive over that same connection, the > latency will make that interaction very slow no. you have full freedom to prioritize the interactive part on application layer (since you mention TCP layer). > the transport medium needs to know how to differentiate > between the two kinds of traffic. no, any other layer could also differentiate the traffic. > you would need a way to set different TCP options on 9P messages for > different purposes. TCP doesn't differentiate well. TCP fairness is not fine-grained enough for this, so i still don't think the transport layer is well suited. what we really need is 9p (file/fd) level distributed scheduling. > > "Joe S" <j...@lifesoftserv.com> writes: > >> Maybe a file server thats purpose is to mux parts of another file >> sounded like fun. My thoughts are that you could then transer thoes >> chunks on a single destination on seperate connections. > > I might be possible to create a file server which interposes itself > between a 9P client and 9P server and bonds multiple network connections > together into a single 9P session. It would be sort of a userspace > replacement for the kernel's mount driver. Wait a minute, this problem > can be solved with a filesystem? Of course... I should have thought of > that. ;) ------------------------------------------ 9fans: 9fans Permalink: https://9fans.topicbox.com/groups/9fans/Te69bb0fce0f0ffaf-M8679a1e06d55c6877dbfbdfe Delivery options: https://9fans.topicbox.com/groups/9fans/subscription
