>i dont believe tcp is the answer. in the vafs work, rx was replaced by >aal5 for data transactions. aal5 is more like udp than tcp. the aal5 >datagrams didnt consist of a number of standard rx datagrams. it was >simply a biggish packet (or pdu) with an rx header. very easy to handle. >there are some other limits in the fileserver that probably 'held back' >filserver performance. if i remember, there is some strange 45k limit >in the fileserver.
The problem with this that I see is that all of the serious thinking about how to make a good-performing stream protocol in the last 10 years has been done with TCP, and _not_ done with RX. So we could duplicate that in RX, which would be hard, or just use TCP, which would be easy. >further, use of tcp would tend to limit scalability/number of clients. I had this discussion with Love in the AFS Workshop; he pointed out that most modern OS's have solved the problem with select()ing on large numbers of descriptors (Solaris has /dev/poll, the BSDs have kqueue, and Linux has something which I forget right now). That seems to be the big one. --Ken _______________________________________________ OpenAFS-devel mailing list [EMAIL PROTECTED] https://lists.openafs.org/mailman/listinfo/openafs-devel
