Ants Beta 0.9.5

[Abyss00]

New update out, Ants Beta 0.9.5.

http://img.photobucket.com/albums/v233/abyss00/ants06.jpg

[ABC_thellookoflove]

Posted By: gwren
Date: 2005-02-16 21:33
Summary: Propagation system upon peer disconnection

I'm working on a feature to propagate a message upon the disconnection of any peer so that the whole net is able to update the routing tables in a way that prevents message losses. This should take a considerable improvement in the amount of effective data tranfered...

Latest version 0.9.5 implements the propagation system that.
It's still potentially not stable! Only JWS version is avaiable by now untill test are done.

[xrobot]

Amazing! This morning I installed Ants 0.9.4, but deal to some unsure problem, I decided to uninstall and reinstall later at night... Now, I just installed it again, and the version is 0.9.5, just wonder why the version change (didn't see any update post in Zeropaid)... Then go back to Zeropaid and see the updated posting! Wow~ am I the no.1 user downloaded and used the new version? Just found 1 peer...... :green5

[Abyss00]

Seeing better DL/UL speeds with v0.9.5 then I ever have before with Ants.

No stability problems yet.

[xrobot]

but the default irc seem downed, right? I miss it so much, just got someone help in the irc last morning....

[CactusChris]

It all seens ok to me - and I got some downloads finishing overnight.......who knows, maybe I have to add some files to the queue soon.
Best Regards
Chris

[fnordprefect]

Installer version now available at Sorceforge.
http://sourceforge.net/projects/antsp2p/

[tsafa1]

I am getting very smooth continious transfers myself with 9.5

[CactusChris]

Welcome back Tsafa - the rumour was you were having such a good time carnivalling that you were going to stay there - glad to see the lure of ANts brought you back.
Best regards
Chris

[ABC_thellookoflove]

9.5. is so quick with transfers, that you think it has lost all anonymity by now direct transfers or one hop proxies, which are not really safe at all. Though, searchresults are not best (not the amount, but the finding and search). And userbase as well.

[CactusChris]

Hi ABC_thelookoflove,
Glad to hear it is going smoothly.
I'm not at home at the moment so I have not got an update - but this morning when I looked it had run well overnight and brought in some files. Does anyone know what the protocol changes were - I must say that Gwren does a fine job - but he is not generous with publishing the change details, and I'm too stupid to read the code and understand. I saw it was a protocol change - maybe other p2p apps could benefit from a similar change??
Best Regards
Chris

[fnordprefect]

CactusChris
Have a look in the News section on the Ants sourceforge page. Gwren has put up a few more details there.

[tsafa1]

this is waht Gwren had to say:

"The long and stable test period started at the beginning of Jan showed
that most of the overhead in the ANts net was due to messages that take
the wrong direction to a destination. This is mostly due to peers
disconnection. Infact when a peer disconnects from the net, the routing
tables of its neighbours usually keep for a while infos regarding the
disconnected peer, exactly as if it was still there. These infos after a
while fade away because new routes are traced by new queries and the old
routes are forgotten by the net. But this process, that basically is the
main idea behind the ANts Colony System, takes time; instead the ANts
net is showed to be a very dynamic system, where things (connections and
disconnections) happend in a way faster than this process can handle. So
to face this problem I decided to apply a propagation system upon peers
disconnections. What is this? Basically when a node disconnects from
another node, they both send to every remaining neighbour a message with
a list of all the peers (IDs) now unreachable (because of the
disconnection), this message is processed and it is also forwarded in a
linear way to all the net, to let peers update their routing tables. To
be precise the message is not trivially broadcasted, I said that there
is a list of the unreachable peers in it, after the message is processed
by a node this list is usually shorted, because there could be
alternative way to a peer, so actually it can be unreachable from a peer
but not from another one. So step by step the list get shorter and
shorter, when the list become empty (usually few steps because there are
MANY different routes to a destination) the message is discarded, so
this is a smart way to propagate the information in a "light way""



Then someone asked him some questions and this is how he responded:

>Are you sure about that? What I found on MUTE was that the messages were
> being sent mostly to all connected nodes due to some timing issues and a
> few other things.

In ANts there are not timing issues... messages can potentially live
forever, the routing is "routes driven",
this means a message will live till almost a route is found. So you see
matters are a bit different, ANts
started with the same MUTE idea, but the implementation is completely
different: random walks and absence of
TTL for messages take different problems than the ones in MUTE.

> The way it is now, if a route is lost (node
> disconnects, and no other choices in routing table) then the message
> gets dropped.

Not exactly... ANts tries to "save" it by looking for other ways if
possible. And retransmitting it a few times to check
different paths. So this is the manin reason why we needed a propagation
system to react against disconnections.

> This happens with the large messages only, the small
> messages really don't add up to much bandwidth wise, I measured that.

I know, but bandwith is precious :P

> So
> you can still use small messages as a "feeler" to find new routes.

This is what is done...

> We
> also send out "FRESH_ROUTE" messages when a new route is needed, and
> searches of course will start a new path.

I don't need such messages cuz the process is integrated in the search
system.

>
> You need to worry about those large messages and be strict about sending
> them only when they can actually get somewhere.

Yeah they are limited, but I also limited small ones... only broadcast
messages are free to "flood" a part of the net.
Other messages are tied to a particular route (so no backtracking, just
forwarding without cycles).

>
> Remember, the request messages should also stop through that path when a
> node drops off, so the big "chunks" shouldn't be routing that way
> anymore (with no other way around).

Plain... another route will be choosen in that case.

>
>> Infact when a peer disconnects from the net, the routing
>> tables of its neighbours usually keep for a while infos regarding the
>> disconnected peer, exactly as if it was still there.

This is what I managed to avoid. Cuz those infos slowed the net a lot!

>
> I can see how that would happen at the one, two or more away nodes, but
> only for the last request sent, and doing a search for other sources or
> routes is a good thing to do, as long as you don't do it too much. A
> "FRESH_ROUTE" message drops all the routing table entries along the way,

mmm I don't like this idea O_o all the work done is trashed this way,
indifferently
work still useful (routes still good I mean) and broken paths.

> so that helps to keep things going. And it possibly creates a new route
> that way too. The searches are better I think.
>
>> that basically is the
>> main idea behind the ANts Colony System
>
> You know, after doing a lot of programming for this, all this "Ants"
> routing stuff (I mean the MUTE Ants stuff) is just basic routing "101",
> there's really nothing "Ants" like about it except that after looking at
> it you could say that it looks something like the way you see Ants in
> real life behave. Even IP routing would look something like Ants so this
> is really nothing new.

Infact it is called ad-hoc routing, internet is STATIC ad-hoc, MUTE/ANts are
DYNAMIC ad-hoc.
In the ip protocol you have to change manually the routing tables when the
topology changes, in ANts or
MUTE if the topology changes the net becomes aware of that and adapts itself
to the changes.
Anyway the multipath and the load distribution in ANts take more than it
apperas from an ANts logic.

>
> The thing called "Majority Routing" is the most "Ant" like thing, you
> can look at it as the strongest scent, and in our case it's simply the
> most traveled path.

I look to the 5 latest marked paths and to the load of each one so to
distribute the message in an unform way
all along the path on each node.

> If this path is broken, then the next available one
> is used in order, etc.. That should be enough to route around a
> disconnect, and if a search is re-issued a new path can be created even
> to a new, possibly faster source.

"Could", but actually it cannot in ANts, cuz disconnections happends in a
way faster than mute. The random walks
break a lot of routes in a single minute, so the net is badly affected cuz
as I said, the process that marks new routes is not fast enough.

>
>> Basically when a node disconnects from
>> another node, they both send to every remaining neighbour a message with
>> a list of all the peers (IDs) now unreachable
>
> I was talking to Eric just a few days ago about a "Bye" message like we
> did on Gnutella. The reason was to send any "reason" messages and other
> data so you could debug problems, "why this node disconnected" and
> things like that.
>

And don't forget to update routing tables ;) tests showed this can improve
performances a lot!

> In your case, I would think long and hard about how what you are doing
> could be used to attack your network.

Yeah, it is a potenzial "door", but it's still hard to be exploited and it
is still a non-deterministic source of information,
so it is not that bad :)

> I could connect and disconnect to
> as many nodes as I can and tell them everything I have ever seen go
> through my node is now gone.

In ANts you can't... you can't actually see anything going through your
node, or to be precise, you could see the small part
of message that take the same route (you are on) to reach the destination
(provided you had been able to be MIM in a precise location
at a determined time... to play as MIM)

> Do that often enough and no new routes
> could get created. I could even track it's progress, every time I
> connect
> I would probably see less and less traffic and know I am doing my "job".
> Maybe I should keep quiet and see if someone wants to hire me as a
> "network slowdown" consultant? :)
>
> I think it's better and more secure for routes to take care of
> themselves in each node

I could agree on this, but I think that passing back the list of
"unreachable neighbour" is nothing more than the dual for
searching for a new route, so it apparently doesn't introduce any leak in
the system.

[tsafa1]

here is some more discusion between Gwren and Nate. Nate is one of the mute (napshare) developers. I found this discussion very informative:

> That may be what you are seeing, old messages going round and round the
> network with nowhere to go.

No, the net prevent this behaviour, the message follow only marked ways,
and marked ways lead to a destination or to a cul de sac (message dies) :)

>
> Random walking is a disconnect isn't it? Not good. Just when a path is
> established you decide to go "walk" to somewhere else.
>
> [ talking about dropping messages ]

That is done only if the node is not active up/down, if there is any
kind of useful activity nothing happends


>
> There's no reason to "save" a message, that's why the requesting party
> sends a retry or re-search, I think it works quite well.

Sure! But it wastes bandwith... so if a message can be saved, that
should be done.

>
>
>>>This happens with the large messages only, the small
>>>messages really don't add up to much bandwidth wise, I measured that.
>>
>>I know, but bandwith is precious :P
>
>
> Yea, it was like 150 Bytes/s, is it worth it?

mmm sadly in ANts the overhead is higher... probably in MUTE you use
simple bits to distinguish message types, in ANts the protocol is
xml-encoded, so I have an higher overhead to handle :(

>
> If that 150B/s I was seeing caused problems down the line that used up a
> lot of bandwidth, then maybe it's a big deal. But you would think I
> would see it here, in the path of the routes for those messages.
>
> The biggest problem with a network like this with proxies is the
> download speed, the MUTE Network should be at about the maximum it will
> ever be, +/- a small amount of waste not over 1K/s.

Use a sliding window... it helped a lot in ANts! Just don't wait for a
former ack everytime you send a new part, cluster file parts and send
parts groups (say, 10 parts at a time). They will eventually take
different routes and will improve bandwith usage. Then before sending
another group of 10 parts wait for some acks (say, just 5 acks among the
10 you are waiting for). You increase the throughput this way (but
latency remains the same :( ).

>
> Whatever you see download wise in about a month is what you will always
> get. Anything else you can do to it now is small stuff and not really
> worth bothering with.
>
>

Just think a bit a you'll find new way to improve performances... I
usually get many ideas every week. It's the time that lacks!

>>>I can see how that would happen at the one, two or more away nodes, but
>>>only for the last request sent, and doing a search for other sources or
>>>routes is a good thing to do, as long as you don't do it too much. A
>>>"FRESH_ROUTE" message drops all the routing table entries along the way,
>>
>>mmm I don't like this idea O_o all the work done is trashed this way,
>>indifferently
>>work still useful (routes still good I mean) and broken paths.
>
>
> It all routes around and works good. No work is "trashed", since we do
> retries using small messages, you can drop a chunk (or large) message
> without worrying about it. I am always interested to see how your idea
> of all this works out, if users see faster average download speeds on
> your network when it gets to be the size of MUTE then I will have to
> look at why.

They are getting higher speed than MUTE with version 0.9.5 protocol
0.0.9 I'm sure... ask a bit around. I solved the dramatic problem of
broken routes with that propagation system and I got impressive speeds now.

>
> Before I get a bunch of messages on that, let me be clear, if a small
> network has one file or two files and everyone has them, you are
> probably directly connected to the source so you will see a fast
> transfer. So when another network gets to be the size of MUTE and it
> gives users a average faster speed, it's time to take a serious look at
> why.

ANts has probably as much nodes as mute... there are almost 40 node
permanently connected (MUTE should be 50 or 60), we are dealing with the
same "problem size" and connections over 3/4 hops are the mean (this is
true for network between 20 and 100 nodes)... Also ANts is actually more
"complicated" than MUTE, in features and protocol. But surely MUTE is
more efficient cuz it codes messages efficiently (bit encoding against
ANts XML one)... You are underestimating the complexity of ANts, ANts is
on the paper far more efficient than MUTE in protocol issues (I read the
MUTE code when I started to code ANts in March), but the overhead
penalizes it very much :(

>
> I think the way MUTE works prevents a lot of different types of network
> attacks and it will route around problems very well.
>

ANts has many features to prevent these things... me and Jason had a
loud discussion over "additional" features I added to the basic MUTE
idea to make things harder to breakers... I could say that ANts is a
specialized version of the MUTE procol, the bases it is built over are
the same, and it also adds some other "freaks" like unique and
non-spoofable IDs, non-repudiation of messages, the "wicked" E2E
encryption etc... :P

>
>>>The thing called "Majority Routing" is the most "Ant" like thing, you
>>>can look at it as the strongest scent, and in our case it's simply the
>>>most traveled path.

i don't use scent... ANts ACO system is a completely different
implementation. It is based on node load and latest marked routes, not
on "scent strength"

>>
>>I look to the 5 latest marked paths and to the load of each one so to
>>distribute the message in an unform way
>>all along the path on each node.
>
>
> You mean Majority Routing that doesn't use the best path but instead
> spreads it out over slower paths. That's what you are calling "load
> balancing"?
>

You missed the point... it's hard to explain in a few line here. Let's
try... Each time a query succedes a path is marked, ok? In MUTE you
apply a scent augmentation function to notify this on each node. In ANts
you keep a list of the marked routes (so no scent on the node) to each
ID on each node, this list is ordered, latest routes come first ok? Now,
each time you have to send a message you choose the less loaded
neighbour among the first 5 possible routes in the list. That is, you
choose among the most fresh routes the one locally less charged.

>
>>>If this path is broken, then the next available one
>>>is used in order, etc.. That should be enough to route around a
>>>disconnect, and if a search is re-issued a new path can be created even
>>>to a new, possibly faster source.
>>
>>"Could", but actually it cannot in ANts, cuz disconnections happends in a
>>way faster than mute. The random walks
>>break a lot of routes in a single minute, so the net is badly affected
>>cuz
>>as I said, the process that marks new routes is not fast enough.
>
>
> Then you have a big problem, stop doing the random walks, I posted about
> that before, it's a really stupid idea. I work really hard to make sure
> connections stay there, even for modems lately.

Actually not... random walk is used to tackle many kind of CSP, it is
very useful is applied in a "smart" way... that is, the walk is not
completely random, it is done (as I said) only when no useful activity
is performed over some routes and it tends to maximize an objective
function (that is the node activity percetile), it can be only useful to
the net, cuz in the worst case you have the same performance of a net
without random walk, in the best case the "node activity" is actually
maximized, so better than a net without random walk. So the issue is not
the random walk itself, but the way it is performed.

>
> Nothing can get routed if nodes keep poping on and off the network. What
> were you thinking?
>
>
>>>>Basically when a node disconnects from
>>>>another node, they both send to every remaining neighbour a message with
>>>>a list of all the peers (IDs) now unreachable
>>>
>>>I was talking to Eric just a few days ago about a "Bye" message like we
>>>did on Gnutella. The reason was to send any "reason" messages and other
>>>data so you could debug problems, "why this node disconnected" and
>>>things like that.
>>>
>>
>>And don't forget to update routing tables ;) tests showed this can
>>improve performances a lot!
>
>
> They update themselves, I tried to explain that. You are going to have
> "security" problems if you trust *any* outside node to tell you what
> routes have gone missing.

That is exactly what happend when you mark scents... (in a dual view).
When you mark scents you tell the net (to each node to be precise) which
node is reachable, I don't see why telling which node are not reachable
could be dangerous. Surely among them there could be also the
disconnected ID, but there will be surely also other IDs (those no more
reachable because of the disconnection of the node), so there is
actually no way to distinguish which ID is related to the disconnected
IP. you get list of broken routes, not of disappeared nodes.

>
>
>>>In your case, I would think long and hard about how what you are doing
>>>could be used to attack your network.
>>
>>Yeah, it is a potenzial "door", but it's still hard to be exploited and
>>it is still a non-deterministic source of information,
>>so it is not that bad :)
>
>
> I explained the attack good enough, you should get it, if not then your
> users will suffer when the network stops. It's not that hard for someone
> to do the attack and bandwidth to do it is minimal. If this is your
> attitude then I wonder what other problems there are in your code
> waiting to be exploited.
>

I'm sure my code has problems... which code hasn't :) But you don't get
the point one time more. The propagation messages are point to point.
They are not related to the "net business". The lay one level under the
routing system, and the only thing one evil node can tell the net is
that some routes passing through it are broken, nothing more, nothing
less, so the effect is the same of a node that blocks every message
passing through it (thing obiously possible in MUTE).

[CactusChris]

Wow - thanks guys - that was a mass update - and generally very convincing. I need time to think about the disconnected node idea - even than i do not think I will catch up with Da Man, but it is nice to feel informed. My wife said "Why do you spend time on that?" (ususal useful comment) - my reply: "Cos I know how it works..." (well almost true). I echo the sentiment about how much better the network is running - great improvement - on the downside I also feel that previous comments about search result not being very good are true. This may be due to what nodes one is connected to - it certainly is true that in MUTE a node that is dropping lots of blocks kills searches dead - but in ANts I get very few results even when searching for fairly common strings. It is time that we made the most of those files available rather than trying to further improve the files that are in tranfer. Removing the 50 files reported per user may help - but I'm not even getting that - often fewer than 30 files on a search for "mp3", any ideas why??

Best regards
Chris

[ABC_thellookoflove]

@ I also feel that previous comments about search result not being very good are true.

The searches are not so bad, because users do not share too less.
The amount of search results are bad, because the search architecture is dammaged.

Gwren said, that with a few hops ( 7x 3 *49 or so) we could reach a horizont of 3 Millions.
This is simply untreu. And is is a lack, beacuse Gwren does not consider this thing as worthfult o change, He often was told, that e.g. my own library sharing must appear TOTAL AND COMPLETE in the search results, if the remote indexing library woudl work.


I often have done this experiment:

Sharing 20 "MORPHEUS" files, connecting to 9 neighbours for several hours.
[argument: All neighboutrs have remote indexed my library]
Then unshare all MORPHEUS files.
Restart ants.

If remote indexing would work, all myb 20 MORPHEUS
files should be found in a search for MOPHEUS.

But this was not the case, only 1 of 20 results was found in maximum,

1. We need in a search result all library hits of my own shared files. It is indoifferent, if they come from my own library or the reomote library of my neighbours, Of course , if remote indexing would work, then it is really indifferent, because the remote woudl be 100 % as good as the own library, But this is not so,.

2. DURATION: Files once seen on the net are deleted by the app after one day or so. This horizont is ok, though iI would like to have search results with timestamps back for one week.


3. PERSITENCE: Files once shared should be found in every node, if the hash is once spread in the remote library. Persistence is a problem if a ID session was canceld or the route is totally new to define.

4. BACKUP: Remote libraries do work only, if the remote library has a backup remote library.
So we need a 2 Hop way of storing libraries.

5. ID-Related Media. Ants generates every session a new ID, this means the DHT is totally wihtou any reference to any IP or ID. The Routes may be updated now, but not the search DHTs , the search every sesssion and esvery search new for the hash, but do not get any ID or IP or even a colony or horizont. In another thread a G2-Hybrid protocol for searches was shown, there we get a ultrapeer style of ants network, to find colonies.


6. The search meachanism has the problem, that the search is done for hashes, but is ants is scaling, we need to search not for hashes, we need to search for cononies first.#
This search must be done with anohter protocol with IP adresses and a supernode / hub archtecture, where all Media of a Colony is indexed and every conlony has an IP adress of the Conony queen
( Supernode).

This will be the biggest step for Gwren to mix IP adresses with ID adresses with the implementation of supernodes into ants protocol.

True is as well, that a search for a certain hash or filename is not working , even not working on a network with only 50 users !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Basically my view is, that with a bigger network the ANTS PROTOCL is not able to do the searches without supernodes and IP to IP connections.

You cannot search for / find a hash, if one in a Million only has the file shared.

Here you need a better DHT system.
Either a bigger level of clusters like cononly searching with queens OTR either a backup of the remote backup in another node.

Last idea: Edonkey needs 5-6 hourse until the transfer starts, this means the nodes are quite stable an a long duration onlione, this is standard if you use the network to have the pc on over night.
Ants is a coming in and out today, if we woudl have more persistent users, the routing tables would be more stable and so as well the remote indexing as well. But this is not the culture for ants now using it over several nights.

I think ants needs some waked up guys for this development, Its a child of you as well chris, especially, if you knwo how it works. So kind regards to your wife. I think it has potentials, not only to save filesharing and free music (though this may be not a common moral thing) but to allow chinese people to read webpages throu other nodes like peekabooty, hope Gwren is developing as well the option, that BBC news can be browsed from chinese ants by / throu european ants.

[CactusChris]

ABC - the more we have, the more we want.... Gwren was probably correct to focus on optimising the routing protocols forst - and he has done a grand job. Now with speeds picking up we need newbies to join and find a lot of files available. Most of the persistant users have many files to share and these are a valuable resource - so searches need to find those files. I'm not sure that I agree with all your points but we seem to agree that improving the search results would be a worthwhile step ;-)
I have suggested in the past that the 50 files per VIP search request return is too small - it was appropriate when the protocol was not so good, and when we were in early beta testing, but now it should be much higher.
Strange - but MUTE's search results can also be a bit flakey.

Best regards
Chris

[ABC_thellookoflove]

@ but we seem to agree that improving the search results would be a worthwhile step ;-)

we need this step and then a better gui and an official release, gweren shoudl do these three steps in the next days and then release an official client befor he is going to irland and ants development is stopped fro half a year,

A beta version with 20 users will not persist a period of half a year without any feedback from the developer.


We need this official release and here search results must be better and then we need a better gui, at least the nuvola iocons from matrix.

[tsafa1]

new minor update today. Same version number. use JWS to update

[ABC_thellookoflove]

tsafa, we need a test on ants.
Please create an unique file, onl yoyu have.
then share it on oe of your machines.

then post an ants link here

Then we try to find the ants link

I bet, we will not find the link.

[CactusChris]

I'm not sure of the manner in which we should do this to be most fair - but I think it is a fair challenge for the system. Maybe we could co-ordinate it through IRC and do the searches at about the smae time. We do need to consider anonymity though - telling everyone the file name in open forums would not be a good idea.

Best regards
Chris

[fnordprefect]

No reason not to, we just have to pick the right file/s.

How about a couple of books from Project Gutenberg, taken at random and zipped up. That combination will be unique, fairly small and not breaking any laws anywhere.

If Tsafa is worried about anonymity, he could run a separate instance of Ants, not sharing any other files for the duration of the test.

[ABC_thellookoflove]

right, just post the ants link here
with a time stamp and the one who could load it, should tell us here as well with a time stamp, when he got it.

[CactusChris]

Just an aside - rather than start a new thread - yesterday when I got home I noticed ANts behaving a bit oddly. 12 downloads active - most at 1.5 - about 3 kb/sec - but the indicator at the top said 1.5. When I looked at it there was abveously nothing coming in at all - searches were still working, peers still connected and data seemed to be flowing - but the dls were stuck. Now I've noticed that the top summary for incoming rate does not always match the sum of the dls, but assumed it was just a timing thing. This was like an acute case of it. All was well on restart, and MUTE was running fine.
Ho hum
Best regards
Chris

[tsafa1]

tsafa, we need a test on ants.
Please create an unique file, onl yoyu have.
then share it on oe of your machines.

then post an ants link here

Then we try to find the ants link

I bet, we will not find the link.

this test was already done by Shreader at DutchAnts. Se my post hear at zeropaid about 47 Kb/s download. I have a screan shot too.

[tsafa1]

Just an aside - rather than start a new thread - yesterday when I got home I noticed ANts behaving a bit oddly. 12 downloads active - most at 1.5 - about 3 kb/sec - but the indicator at the top said 1.5. When I looked at it there was abveously nothing coming in at all - searches were still working, peers still connected and data seemed to be flowing - but the dls were stuck. Now I've noticed that the top summary for incoming rate does not always match the sum of the dls, but assumed it was just a timing thing. This was like an acute case of it. All was well on restart, and MUTE was running fine.
Ho hum
Best regards
Chris

I have seen this behavior occasionaly too. copy the log from the console and email it to Gwren when you see weird stuff.

[ABC_thellookoflove]

what we need for ants is a board with ants links, where users can add ants links like suprnova.org, only for ants!!! Any polish one here to create a board like this ?

[fnordprefect]

Allow me to oblige: http://bitzi.com/society/AntsP2P
You can donate submissions to the ants_anonymous username if you don't want your own ID attached to a record.

You can also paste in the Ants2K link as a comment but seeing as Ants has ED2K links now, there's no need.

For the ultra paranoid, use TOR+Privoxy or I2P to submit.

[ABC_thellookoflove]

we need ants links board, cause ed2k links are better loaded in emule.

[Abyss00]

Small update to Ants Beta 0.9.5, the version number did not change.

[tsafa1]

i send gwren the following email. i'm not sure good idea to remove search limits yet:

"i am still seing 100% cou usage , most likly due to sharing 115 gb.
i was considering unsharing a lot of stuff but i got another idea.
currently ants conserves resources by only allowing 50 search results from each peer, right? well my idea is the flip side of that. when an incoming search finds 50 files that match the criteria, the incoming search is terminated.
i think i am being killed by wild card searches for .mpg , .avi and .jpg i have about 15,000 of those.

what do you think? should i just share less?"

[tsafa1]

Gwren issued a new patch today via JWS (same version number 9.5) to address my cpu issue. I am seeing an improvement in cpu so far as well as a nice increase in upload speeds. i am guessing that because the cpu is not working at 100% it is now free to direct uploads more smoothly. this problem was pretty much only for me beacause of the 15,000 files i am sharing. The incoming searches where killing me. 9.6 has just been released with all these changes.

see my latest screanshot showing upload speeds.