>From Dan Merillat <[EMAIL PROTECTED]> >Incidentaly, there's no reason NBIO is required for this. As small as FN is >right now, you can put two blocking threads per connection and limit yourself >to one connection per remote node... one reader, one writer. I've got to >re-read the FNP doc to verify there's nothing sticky with multiplexing queries >on one channel, but it looked fine to me. > >Comments? I realize this is a major infrastructure change. I've had to do >reflows like this on other projects and it's always a bitch. The question is, >do we think it's a more efficent method of handling the traffic then >one-thread-per-query. > >--Dan
I don't think anyone else replied to these points, but it's nontrivial to multiplex FNP to one connection per neighbor--connnections can block transferring trailing fields (the actual data when the data is found) for extended periods of time waiting for data from further upstream in the network. you'd have to convert FNP trailing fields from a stream model to a packet model to do one connection per neighbor. NBIO would still be nice, even if there was only one connection per neighbor, since popular seed nodes can potentially have a very large number of neighbors (more than in the routing table, like transients). -- Benjamin Coates _______________________________________________ devl mailing list [EMAIL PROTECTED] http://hawk.freenetproject.org/cgi-bin/mailman/listinfo/devl
