Share EX2 info.txt (2006-04-01) Changed somewhat. Didn't have high speed network environment until recently. Then when I checked various things, I noticed that speed is not going up. I optimized it to for environments capable of doing 1000KB easily. Internal bandwidth control implementation is also tweaked to have nice transfer speeds. It should go up to the set limit, right? "That" might have became a separate project. ---------------------------------------------------------------------- Share A82 info.txt (2005-03-31) The source base can't be shared with the NT version, but some of the functions are shared, need to update them at the same time... Wasn't too much to worry about, but damages to Share due to bugs from plugins have been reduced. This is implemented in NT too. The reason why NT's PDK hasn't been released was because of this problem, and to prevent buggy plugins from obstructing with the experiments. ---------------------------------------------------------------------- Share A81 info.txt (2005-02-28) Structural analysis? Checked again whether there is a bug or not. There is no bug after all, I take back what I said earlier (about part of the cache not being able to be searched). Probably only happens in environments with some very rare memory errors. It's true that it has been operating continuously for several months, and it happened a few times in the past. HDD died once too. More like it's not an access violation caused by bugs in the algorithm. Maybe it's because of problems in the display? Number of items in the container is controlled through FCount, which decides the number of loop iterations. New items are appended to the end of the list. If for some reason, this FCount is not updated and is smaller than the actual value, newly added items will not be displayed. It's true that when I think about it now, because the new caches are not getting displayed, this theory would explain it. There are other reasons why this can be confirmed but I won't explain it (it's long and tiresome). About NT, I believe the speed test margin and the maximum instantaneous speed calculation algorithm is broken in miraculous ways, making the number of connections difficult to change. Since there has been reports saying when the number of connections becomes zero, it's reset, then it starts connecting again, at least it seems to be operating as expected. I wonder if the Resend value is changing. If there are no local packet loss and no resends, the speed can reach roughly 100Mbps. But if there are delays or anything, resend will happen. Well, until the environment is fixed, I will work on other things. The NT version uses almost the same code as the TCP version, but there is no compatibility between them, so it does a few major extensions. It supports more generalized and unknown formats used in Search. Resume context identifier is extended to 128Bits (part of the implementation to dividing query results in sends). Debug code is checking certain timing logic. ---------------------------------------------------------------------- Share A80 info.txt (2005-02-26) I recommend restarting from time to time? While checking the operations, it's confirmed that there exists a bug where part of the cache can't be searched. It happens under specific conditions after cache delete code is executed. Seems to happen when you have a large amount of cache. The data exists internally, but those data can't be searched. After restarting, those cache that couldn't be searched appears normally. This may be quite a fatal flaw. Memory leaks or anything like that doesn't happen, but this may explain why under special environments, the memory consumption might increase. If people had reported operations properly, I wouldn't have left the bug up to now. Node, DB, cache, keys, and various other bits uses the same container class, I am worried if there are similar problems occurring elsewhere. IPv6 might be popular this year. The reason why there almost no compatible machines might be because routers and firmwares do not support it. I researched various things, and seems like it's possible to do multicast on the internet using IPv6 (under certain conditions). Seems interesting, but there is no time at all to put the code together. Even before that, there is no environment for it. For the future, I want to abandon IPv4 and use IPv6. On the VNet side, the design is somewhat tied up and not. It can't be tested if the ExDP side is not more stabilized. For other programs that uses DHT, I wonder how they implement the security parts? It couldn't be that there are no security at all, right? Somewhat related to this, the update this time includes strengthening security. ---------------------------------------------------------------------- Share A79 info.txt (2005-02-20) A79 changes the cache.idx format. It's not downward compatible. UDP test code removed, since it's confirmed that UDP packets will pass through. UDP version is working already, but release will be delayed for a bit. The test environment is not prepared yet, and some time is still needed to test the operation of the new version. UDP version's initial nodes will registered in a new file. Feels like this, by the way: +---------------------+ | Share | +---------------------+ | ExDP | | +--------+----------+ | | Stream | Datagram | +-+--------+----------+ | UDP | +---------------------+ | Internet | +---------------------+ I want to keep it like this until 2006: +---------------------+ | Share | +---------------------+ | VNet Client | +---------------------+ | | TCP | +---------------------+ | VNet Server | +---------------------+ | ExDP | | +--------+----------+ | | Stream | Datagram | +-+--------+----------+ | UDP | +---------------------+ | Internet | +---------------------+ Anyways, XP SP2 can't send TCP/UDP as RAW packets. Because I can't solve the loopback problem, I thought maybe I should make a tool to capture those packets and send them back, and realized SP2's limitations when I couldn't put one together very well. On the UDP side, I am tricking it by sending normal UDP packets, but feels like it will be troublesome to get global IP address so I will leave it after all. Seems easier to just buy 2 routers. I am writing this because I thought someone tried it, but no one did -- A scheme to access modems using routers. I am thinking on the LAN side, the reason why loopback doesn't work is because the router can only forward ports on the WAN side. The reason why it's implemented that way may be to decrease packet processing and increase throughput, or maybe it's a security policy, or just the designer's preference. I have doubts whether LAN packets can pass through to WAN side, but if only packets from the WAN side can be forwarded, this scheme should succeed. Maybe it's impossible with switching hub... I would be worried if I throw away anything other than PPPoE packets. WAN | +-------+ | Modem | +-------+ | +-----+ | Hub |--------+ +-----+ | | | |WAN Port | +--------+ | | Router | | +--------+ | |LAN Port | | | +-----+ | | Hub |--------+ +-----+ | +----+ | PC | +----+ ---------------------------------------------------------------------- Share A78 info.txt (2005-01-23) Decrease maximum CPU load on threads. It's not like things become more lightweight. More like the processing codes increased overall. Load is decreased due to reduced consumption rate of CPU resources, so it appears as if things has gotten lighter. Using this option causes response rate to decrease, use it as you wish. By the way, general thread and timer thread are each limited to maximum 25% load. The limits on "how old an version can download from a new version" has been changed. Thus it's meaningless to stay on an older version forever. If the maximum downstream speed value is set much higher than actual maximum, Share's connection speed will be decreased. This speed is determined by Search connections, naturally nodes with higher maximum downstream speeds will have greater portions (of bandwidth) dedicated to Search connections, the end result is that the Share connections' speed will be dropped. Don't know if the next feature will be Diffuse verify or UDP. The new speed control will probably be in the UDP protocol. ---------------------------------------------------------------------- Share A77b info.txt (2005-01-21) Experiments to migrate to UDP will start soon. UDP will be emulating TCP behavior, it's there to get around various limitations of TCP. If the UDP is open, the node will be marked and recorded as "UDP ready". There will be simple UDP communication tests, please configure your firewalls. UDP uses the same port number as TCP. UDP version will extract "UDP ready" nodes from nodes.db. Look forward to a seamless transition. Well, seems like we can use that this time too... Be sure to report Share's operational status. For example, regarding CPUs, because of differences in thread context switch times, there are bugs that only appear under special environments. Because of the lack of proper reports, there are bugs that remained for more than a month. Bug reports without operating environment will be given a lower priority to be worked on. Filters will be applied to clusters. If a filter is matched, the priority will be 0. In case where it's 0, unless the node hasn't been optimized, the connection will not be relayed. Make sure that clusters do not match filters. If a lot of cluster words or different genre words are combined, the node may be repelled by neighboring nodes due to filters. Node list DB is constantly being optimized. Low priority and error nodes are deleted, and will be replaced with higher priority nodes with expected keys. Maximum is set to be 10000, but that seems to work fine so it's fixed at that value. Isolating bad nodes... this part is strengthened from before, nodes sending improper timestamp or data keys will be disconnected. Have you seen any strange keys lately? Development speed might have dropped due to the start of some closed beta.