[ANet-devel] Re: You guess well...

[Benoit N. <be...@ma...>]

John Mitchell wrote:
>Let's talk for a moment about the types of data that will be passed by
>ANet. Now floating around will be chunks of data... typically what files
>are available, etc. However this doesn't have to be the only use for this
>data. Service data could be scuttled around in the same manner. For
>instance, instead of browsing a list of files, how about browsing a list
>of what services a person has available. Here's an example, due to the
>need to optimize a distributed network, a person may not be getting a view
>wide enough to find the content they want, but let's say a server within a
>users range is running a operating a service to stretch the search to the
>end of it's range, or maybe a service to filter out irrelevant data to
>find very specific information (a search that has other aspects written
>into it than that that a normal user GUI would have). I guess these would
>be similar to applets, except more for optimization than anything else.

In my opinion, the way the network works should never, ever change, even if
some service would need that. This is because the way data is distributed
on the network is within the protocol and shouldn't care about what
services are running on top of it. What I'm trying to say is that since the
protocol will "accept" any services, someone could easily spam the network
with his/her "service" that would contain only random data and that would
"need" more network bandwidth.

So, you're 100% right when you say "a service to filter out irrelevant data
to find very specific information", in the sence that some node have the
liberty to filter the data or to increase its range (by increasing the
"hops to live"). But how much of that should be allowed (before your node
is considered a "spamming" node) is very tricky...

>Now let's assume, every user of ANet is running some type of server
>(regardless of whether it's actually serving anything or not). What they
>could actually have is a very powerful backbone for operating other
>services.
>Now if each node can be upgraded as easy as installing a patch or
>recompiling with new modules it will be extremely functional and useful.
>Let's say one user operates a node, but it's primarily for private use (he
>uses it to hold private text conversations) he should be able to upgrade
>his node to act as an extented chat server.
>Another example, let's say a person wants to operate a sort of web server
>with again very private content. A person should be able to do that the
>same way. The important things to remember is that ANet's foundation now
>will determine how easy a transistion can be made to new functionality
>latter. There's going to need to be some serious conversation to work out
>details for the whole process, and I'm all about finding new ways.

We'll need to think "in advance" for things like public key encryption so
that it will be easy to add that in the future, for example.

>I think the Core Module is going to have to be left very open for the sake
>of later improvements. There isn't enough room to play with things in the
>TCP/IP module, because that would require finding a new way of doing
>everything for every OS ANet runs off of. I don't know exactly how you see
>the layout for the high priority tasks, but when I read about them I
>assumed that the Direct On Port Data Transfer would be right along side
>the Core Module in program operation.

Direct On Port Data Transfer is just an abstraction layer between the Core
and TCP/IP to make sure that the Core doesn't need to care about the TCP/IP
connections (TCP/IP module), and the connection process and which port to
use (Data Transfer modules). So, Direct On Port Data Transfer only chooses
a port, initiates the connection with the help of the TCP/IP module and
sends

>I do have a questions about the GUI Module though, will that module be in
>charge of collecting information for a client application, or is it the
>client application itself? I think the former would definately push others
>to develop there own interpretations of a client, but the latter is going
>to be necessary in any testing phases... even if it does get recycled down
>the line.

In the end, I think that ANet should be only a deamon, running as a
backgroud process (or whatever they call that in Windows). I recently made
a posting on the mailing list about that. The clients can only specify
which service numbers you're interested in (like port numbers), and insert
data on the network for their own service. But the actual caching, for
static data for example, is handled entirely by the ANet deamon. So, we
won't need to do any GUI for the "core" of ANet (Core, Data Transfer,
TCP/IP), while the clients (GUI and Services) will handle the rest. The
"Core" doesn't need a very sophisticated GUI anyways (for debugging
purposes). Some settings files and a very basic output with stdio (log file
or console) should be enough. I know it's not very user friendly, but this
is pretty much like other UNIX deamons anyways: play with the settings
files, lauch the deamon, and don't care about the rest...

(We should move this discussion to the mailing list...)

- Benad