From: Radim K. <hs...@se...> - 2010-07-20 00:14:34
|
FSP needs to stay simple protocol. If we make long feature list then it will be complicated to implement. Look for example at HTTP/1.0 protocol, its very simple. * More structured ways of querying the server's capabilities and can you give an example on it? it should be enough to have it IMAP like. List of keywords with optional argument. > * (Auto-)negotiation of retry times. The current protocol is optimized > for low-loss high-latency circumstances. It could for example perform > much better on low-latency high-loss wireless networks by retrying > much sooner. Better to add possibility to query minimum retry times. Client can always do slower. > * Windows: this can improve speed without much costing that much in > state. Throttling can be achieved using more conventional and flexible > mechanisms too. It should probably be negotiable between client and > server. I do not like idea of Windows. we will need reinvent wheel and do TCP style ACKS and SACKs. Its much less coding to use TCP instead. Keep it simple like FSPv2 is in style REQUEST -> REPLY. > * Support for more than one connection per IP address. This might also > be negotiable between client and server. > * Large file support: in 2010 this may be the biggest disadvantage of > FSP. Can't use it to distribute big files. > * Better authentication and authorization. Cleartext passwords don't > add that much security. > * Optionally support encryption. Preferably through DTLS. if we will have more state full protocol we can add something like SASL. Encryption will be required because it will be very easy to spoof packets because of UDP. * Reduction of the number of packets sent by compounding them when possible. Good idea |