Share NT5 info.txt (2005-03-30) ExDP stream might become TCP. Currently it's implemented with UDP, but it's becoming troublesome (especially to tweak it). More like streams can be implemented to be bandwidth constrained. On the UDP side, it will stay for datagram use, since it's code used to connect to IPv6 too. It's about time to start implementing that. I am still deciding on what language to implement it in. For now, I will try coding it in several languages. It will take at least 3 months of development time. Data transfer scheme is completely renewed. Probably closest to Freenet. Relays probably won't happen, they must be done using the concept of diffusing traffic. Both the sender and receiver can be transferring anonymously, so there is no point for relays. Let's keep it at that so that believers in relays don't get too excited. Instead of solving the problems of data transfers and addresses, keyword search is more difficult. In theory, if all hosts are searched, we might be able to find what we want but the efficiency is too low. Still, implementing constraints to collecting information locally is difficult with pure peer-to-peer. The traffic will probably become terrible in that case. I have plans for registering search words, which is manual setting of those words. Searches will happen only for strings matching the same byte sequence with the registered words. For example, if "ABC" is a registered word and ABC10.zip is a public, searching for "AB" will not return results. To find ABC10.zip, the user must search with "ABC". In this situation, we can search only hosts with registered words (DHT). There are a few problems with this method too. With some words like ".zip" that includes everything, if it's constrained to a single host, the traffic becomes localized. To avoid this... what should I do, I wonder? Currently for NT versions, CPU load increases easily when client is sending. This doesn't happen locally, why??? Probably on small I/Os, the CPU load would increase, and maybe it only happens when sending through slow connections. ---------------------------------------------------------------------- Share NT3 info.txt (2005-03-17) Session explanation. This is going to be gone eventually though. ssClosed Initial state, haven't been displayed (closed). ssSyncSent Sent connection request, waiting for ACK. ssSyncRcvd Received connection request, waiting for ACK. ssEstablished Send-ready state. ssWaitSendFin Sending FIN until send buffer is empty. ssWaitFinAck Waiting for ACK to corresponding FIN. ssWaitClose Waiting for FIN on the other side. ssTimeWait Free state. Addr Encrypted IP/port. ID is like TCP's port. ID numbers are increased sequentially. Since each service is independent, it's a simple implementation. ExDP's 16bit service number and the 16bit ID (session ID) together allows for 2^32 connections per socket. The actual number is limited to usable resources. Time is the elapsed time since connection attempt. Order_Skip Number of out of order packets. More likely to increase when packet loss happens. In the old (TCP) version, timeout processing is done on on the Share side (upper level), but I plan to combine it with the timeout processing on the lower level, but totally forgot to implement it. Deadlocks doesn't happen anymore, right? I plan to make it not negotiate with the lower versions (NT2). ---------------------------------------------------------------------- Share NT2b info.txt (2005-03-15) If there is a connected session that did not communicate for a long time, there is a bug that may cause it to timeout. It might be connected with only keep-alives though. It's difficult to reproduce, and the cause is unknown. Temporary solution is to reset internal states when the connect button is in the OFF state, maybe those session will be released. Might be good with "disconnect all" too. More like those stay connected for a long time in Test state. Maybe the keep-alives and timeout code are in a conflicting state. Packet losses didn't happen as much as I thought. But as expected, when other programs are taking bandwidth, it's more likely for resends to happen when sending packets above maximum transfer speed. Seems obvious, that when packets above the transfer capabilities are sent, those overflowing packets become abandoned. Recv_Stream value is not changing. Seems like I forgot to update it. The other values that are not changing haven't been implemented. CrcErr is implemented, but usually does not change. There is no reason for packet datas to be corrupted in the first place, other than in the case of some crappy routers. On using some packet capturer with IPv6, I got some strange header warnings, don't like that. Is it the router's fault, or maybe the capturer is an idiot?