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.
