How Big Can an Anonymous Net like ANts or Mute Get?

[Hornet]

During testing ANts users have experienced both fast(50 K b/s) and slow(2 K b/s) download speeds - fast when the network was small(10 users) and slow when the network was bigger(40 to 60 users).

So how big can an ANts (or mute) network become before it is too slow to be useable?

Can these scaling issues be solved or do such networks inherently have to be small?

Jason Rohrer the developer of the original ad hoc ants network application MUTE has tried to answer some of these questions in an interview on http://www.onlamp.com/pub/a/onlamp/2004/08/12/mute.html?page=1:

Jasons says the larger the number of users, lower the average user connection speed and the higher average number of downloads per user then the SLOWER THE AVERAGE DOWNLOAD SPEED OF EACH AND EVERY USER.

If you want uploader/downloader anonymity, you simply cannot use direct downloads. Indirect downloads always involve a substantial performance and scalability hit. Even if you ignore the effect on overall transfer speed, you still have at least one additional node involved in each download, which in turn increases the load induced by each download.

For example, suppose you have a direct download network of 100 nodes that can support 50 simultaneous transfers — half the nodes are uploaders and half are downloaders. If you now force each transfer to involve an additional intermediary node, while keeping similar bandwidth constraints, you can only support 33 simultaneous transfers: one-third uploading, one third-downloading, and the other third relaying.

I will claim that using a single relay or proxy for each transfer doesn't provide enough anonymity. How can you trust your chosen proxy? What if the adversary happens to be operating the proxy that you choose? The same holds true for any system that uses fixed number of proxies for each transfer. If all transfers use two proxies, and you happen to pick two "adversary" nodes to proxy your transfer, your anonymity is compromised.

MUTE uses a variable number of intermediary nodes for each transfer, with the network topology dictating how long each transfer chain is. No matter how many nodes in a transfer chain are controlled by the adversary, the adversary can never be sure that it controls all of the nodes in the chain. Thus, the adversary can never obtain the identity of the uploader or downloader with any degree of certainty.

Since there is no fixed limit to how many nodes a MUTE transfer can pass through, there is also no limit on how much load is induced by a transfer or how slow that transfer will be, and this is where the scalability concerns arise.

Each additional user in the network is likely to initiate additional downloads, which will each increase the load on the network. Of course, if you want decent anonymity, you must make this kind of tradeoff.

To answer questions about how well MUTE will scale, we need to answer other questions first: How slow must a transfer become before it is considered useless? How much bandwidth will the average user dedicate to the MUTE network? How many downloads will each user be requesting? As an extreme example, consider the case in which no one is downloading anything: MUTE can scale limitlessly. At the other extreme, if everyone expects fast transfers and wants to be downloading 100 files simultaneously, MUTE won't scale beyond a handful of users.

Also, I think it depends on how much users value anonymity. A slow anonymous download may be more valuable than a fast download that could land you in court. The same tradeoff operates for quantity: one anonymous download a day may be more valuable than 100 non-anonymous downloads.

As an example, we can assume that a transfer is worthwhile as long as it is coming in at over 5KB/second. If we assume that everyone has a cable modem with a tight upstream bottleneck, then each node can handle relaying or uploading about three files simultaneously. Next, we can assume that each download passes through four intermediary nodes on average. If we have a network of 1,000 nodes, then we can support at most 600 simultaneously downloads at decent rates — each download taxes the upstream bandwidth of five nodes, and each node can handle being taxed by three simultaneous transfers.

Of course, these calculations change as the assumptions change, but we have just laid out assumptions that would suggest that MUTE could support 60% of its users downloading one file each at worthwhile rates. As the percentage of downloaders increase in this network, the download rates would decrease throughout the network.

With the above assumptions, each additional node contributes three transfers worth of bandwidth, but would consume five such units of bandwidth if it were to download. If we reduce the worthwhile transfer rate to 3KB/second, then we achieve a balance: Each additional node can request a download, since it contributes the same amount of bandwidth that its download consumes, so MUTE could support 100% of its users downloading one file each.

If users curb how many simultaneous downloads they request and are content with the resulting transfer rates, then MUTE can scale limitlessly.

However, if everyone else is "playing nice," you can increase your personal gain by initiating additional downloads for yourself and abusing the network. Keeping this kind of greed in check is difficult, especially in an anonymous network.

[notbob]

i bet the 3 people thinking about trying ants just read that and decided against it

[aqlo]

This is a nice honest post though, with actual content.

Shareaza had a big scaling problem back when they were first trying out the G2 network, they seem to have gotten over it (to the extent that have gotten over it) by rigorously testing the supernodes concept until they arrived at something of a happy medium.

To accomplish this though they really did have to have their own private network, when they tried it in the original gnutella network they just pissed everyone off.

I don't know if this is good news though, the supernodes concept seems alien to any attempt at anonymity, for large data trasfers at least.

PS: Well unless you mean the spam font notbob, yeah that might freak out the timid little burrowers.

[Siskabush]

Man, will these fanboys stop spamming thier damn program?

[FreakinWeasel]

Doesn't sound much like fanboy to me Siskabush. The guy is telling you that if there are more than few users on Ants then the network is screwed? Maybe it's just me but if he is selling Ants as a good replacement for any p2p I use, then he needs to work on his pitch!

[MushroomheadXIII]

Man, will these fanboys stop spamming thier damn program?
It is fanboying, whenever a post is made by them, their program is always included in it, one way or another.

[AussieMatt]

Um this thread was in the Ants forum .A forum to discuss Ants and and technology surrounding it like proxy chaining ,encryption and IP masking and legal issues that arise from using these techniques also technical issses like can the algorithm scale and if the program even works

.Ants is heavilly developed by one developer at the moment and he makes changes and or bugfixes somtimes on a daily basis,I feel sorry for you Win MX refugees that had to wait over a year for any fixes and beta versions from Frontcode.
Having a Ants forum means people are going to disscuss Ants and keeps the Ants threads in one forum. If you dont want to see them on the front page dont respond and they will go away soon enough or complain to a Moderator.Your protests will probably fall on deaf ears seeing the Moderators set Ants and MUTE the forums up in the first place.

[nms04]

not big!! mute is actualy too slow and ant's has connection problems and too few files

[AussieMatt]

MUTE has different routing policys to Ants and no multsource or swarming downloads, so this could be part of MUTE's problem .Jason did this article a few months ago and is reportedly working on MUTE 0.4 so he may have a solution to this problem by now.

EDIT - This Article was written on August 12,2004 Just about when Grwen released Ants Beta 0.0.1

[Hornet]

MUTE has different routing policys to Ants and no multsource or swarming downloads, so this could be part of MUTE's problem .Jason did this article a few months ago and is reportedly working on MUTE 0.4 so he may have a solution to this problem by now.

EDIT - This Article was written on August 12,2004 Just about when Grwen released Ants Beta 0.0.1
AussieMatt Jason's article is not about MUTE routing policies. Multisource or swarming downloads just make for a bigger problem.

The issue is not related to MUTE or ANts it is related to proxies. A direct connection uses the bandwidth of one user. A proxy connection uses the bandwidth of several users therefore reducing the capacity of any proxy system. The more hops the greater the reduction in capacity. The bigger the network the more hops the slower the download.

However the real problem is packet loss, due to network congestion caused by bottlenecks in a big network, as lost packets are resent. This makes the congestion worse eventually leading to deadlocks which stop any data being transmitted at any speed!

There are many solutions including:
1)Using network feedback to manage user demand on the network (as well as routing) http://sourceforge.net/forum/message.php?msg_id=2881862
2)Using social pressure to explain to users why they should limit their downloads or not download to enable the network to have spare capacity to proxy. http://www.dsg.cs.tcd.ie/dynamic/uploads/category54/3.pdf
3)Gwren (ANts creator) is actively working on solutions that regulate node traffic so preventing packet loss and therefore ensuring that bandwidth is not wasted. http://sourceforge.net/projects/antsp2p/

Also, you in the past have suggested clustering of nodes like in Winny to reduce hops and so boost network capacity and speed.

Hornet

[AussieMatt]

Suppose clustering is one reason Winny and Share work so well , and the fact that Japan has a high adoption of broadband so the probelem's releated to bandwidth and bootlenecks due to low upload/download speeds are not a problem anymore .The Share english docs for example state that you shold use a T1 or better to make Share work.No problem in Japan or Korea.

If you want to be a mouthpiece for Gwren you better read what he has to say about scaling issues related to Ants and MUTE first
Grwen on the MUTE forums
I think... this is the reason why swarming, multiple source download, and
rateless systems are indispensable in such nets! http://sourceforge.net/mailarchive/forum.php?thread_id=6093013&forum_id=37474

EDIT: this is Grwens reponse to the first post in this thread.

[Hornet]

Suppose clustering is one reason Winny and Share work so well , and the fact that Japan has a high adoption of broadband so the probelem's releated to bandwidth and bootlenecks due to low upload/download speeds are not a problem anymore .The Share english docs for example state that you shold use a T1 or better to make Share work.No problem in Japan or Korea.

If you want to be a mouthpiece for Gwren you better read what he has to say about scaling issues related to Ants and MUTE first
Grwen on the MUTE forums
http://sourceforge.net/mailarchive/forum.php?thread_id=6093013&forum_id=37474


OK Aussiematt here is my GWREN quote in relation to ANts having both multiple source downloads and swarming:
ANts has both... and uses also a sort of rateless code to optimize
information diffusion,
but I really don"t know if this will be enough with so many adsl connections
around the net :( http://sourceforge.net/mailarchive/message.php?msg_id=10222653

IMHO the fundemental issue is tha amout of own traffic to network traffic, be that multisource /swarming own traffic or simple download own traffic. If ANts' nodes don't ensure that enough network traffic gets through then the whole net slows then freezes (due to deadlocks).

Note. I think this issue can be solved and that Gwren can solve this issue in a short space of time.

Maybe, until then for fast download speed use ANts in small networks.

Hornet

[nms04]

winny is "anonymous" but fast too, ant's wouldn't be that bad if gwren would rework the connection mechanism ... it would probably be cool if gwren (ants) and jason (mute) would work together so they would be able for sure to create something useful

[AussieMatt]

NMS Antns gives the 3 options to connect not Just IRC you can connect with IRC ,JETI (Jabber Instant Messenger) or Munualyy by adding a trusted peer. Webcaches can be attacked and its alot easier to move to a new IRC server and channel than it is to set up a webcache also you can set up many IRC channels with ants that dont interconnect or bridge back to the Main network with a webcache this would be hard to do.

[ABC_thellookoflove]

slitting the ants network into many ric channels maybe closed is a horrible vision !!
ants is not kdrive ! We need ONE network as well wih hornet, better with mute as well

[Hornet]

MUTE has different routing policys to Ants and no multsource or swarming downloads, so this could be part of MUTE's problem .Jason did this article a few months ago and is reportedly working on MUTE 0.4 so he may have a solution to this problem by now.

EDIT - This Article was written on August 12,2004 Just about when Grwen released Ants Beta 0.0.1

Thanks for the reply to my orignal post, well researched as usual.

But I'm not sure what you mean AussieMatt.

Are you saying that ANts does scale now or will scale in the future?

In a previous post http://www.zeropaid.com/bbs/showpost.php?p=281135&postcount=122

You say:
Ants is designed to work in small groups anyway somthing like WINNY does with clusters where you join a group with simmilar interests .

You also quote I2P stating that ant routing does not scale well:

The I2P Analysis of MUTE and Ants is promising saying that plausable deniability Ants based routings biggest asset and legaly is probably Ants based routings saving Grace That is until the INDUCE Act comes along .
Ants projects goals are not to to provide legal protection but to provide file transfer annominity .MUTE on the other haed was designed to give legal protection against the Entertainment Industry's lawsuits Ifnyou look at the websites of both Ants and MUTE you will see the difference.

Analysis of MUTE and Ants from I2P (a open source annoymous proxy service)
"Both of these systems work through the same basic antnet routing, providing some degree of anonymity based on the threat model of providing plausible deniability against a simple non-colluding adversary. With the antnet routing, they first either do a random walk or a broadcast search to find some peer with the data or identity desired, and then use a feedback algorithm to optimize that found path. This works well for applications that merely want to know what other people around them have to offer - "How are y'all doing" vs. "Hey Alice, how are you" - you basically get a local cluster of nodes that can share files with and maintain some degree of anonymity (though you don't have much control over who is in that group of peers).

However, the algorithm does not scale well at all - if the application wants to speak with a particular peer it ends up doing a broadcast search or random walk (though if they are lucky enough for that to succeed, the antnet routing should optimize that found connection). This means that while these networks can work great at small scales, they are not suitable for large networks where someone wants to get in touch with another specific peer. That does not mean that there is no value in these systems, just that their applicability is limited to situations where their particular issues can be addressed

Does Gwren believes it is posible to have large networks using ANts p2p providing the flooding issues are resolved?

I think the scaling issues can be resolved by Gwren using traffic management; network feedback using an emergent algorithm or users limiting downloads or a combination of all three

Hornet

[AussieMatt]

Work needs to be done Gwren at the moment is trying to fix Ants syncronisation but when he changes somthing another problem emerges suppose thats why its still in beta test .

Grwens plan is to set up comunities so he says and they will have a pgp key to join that comunity on reason for end to end and you secure your channel/comunity with pgp keys .
These communities could be in the 100's or 1000's but as winny's system of clusteriseation people of simmilar interests will be grouped together and localised .
Winny for example tends to cluster all the US users in one group becuse they use english keywords to join clusters and clusters group people of simmilar interests so it makes it easier to search for the files you want .
Not a new concept but a good way for ants to optimise itself and its search results also makes sources more readilly availible .Soulseek has dedicated channels and it makes it quite easy to search and find that rare punk ,ska or io music youve been looking for .

[Hornet]

Work needs to be done Gwren at the moment is trying to fix Ants syncronisation but when he changes somthing another problem emerges suppose thats why its still in beta test .

Grwens plan is to set up comunities so he says and they will have a pgp key to join that comunity on reason for end to end and you secure your channel/comunity with pgp keys .
These communities could be in the 100's or 1000's but as winny's system of clusteriseation people of simmilar interests will be grouped together and localised .
Winny for example tends to cluster all the US users in one group becuse they use english keywords to join clusters and clusters group people of simmilar interests so it makes it easier to search for the files you want .
Not a new concept but a good way for ants to optimise itself and its search results also makes sources more readilly availible .Soulseek has dedicated channels and it makes it quite easy to search and find that rare punk ,ska or io music youve been looking for .
Aussiematt can you use Winny as an example as it only clusters for searching not file transfer?

[AussieMatt]

From chars english Winny guide over at Slyck I get this
What is "Clusterization"
"Clusterization" is the unique idea of Winny, and it has done in order to raise the ease of obtaining of a file.
The Winny users which exist in near in the network connect each other mutually.
Since there is no central server in Winny network, file information is not manageable unitary.
Winny has taken the method of collecting file information from surrounding users.
However, if the scale of a network becomes large, the exchange infomations with a long distance users will become difficult.
For solution of this problem,Winny will divide group of users who like same kind of files called "cluster".
If you join right claster,You may obtain files more easily.

How to made cluster by Winny
First three keyword called "Cluster word" which make Cluster.Cluster word make clster by Winny system.
Cluster is group of users.It is organically created by the network,not by users.

Clusternization mechanizum is very complicate.I can't understand everything.However I'll explain very very simple.

User A set cluster words of "music" "mp3" "album"
User B set no cluster words
User C set "TV" "avi" "mp3"
User D set same as User A

User A and D conect most easy and strong.
User C and A or D conect next easily.
User A and B,B and C C and D conect not easy and not strong.

Therefore If you need music files.If you set some music related words.
You can easily conecct other users who to your taste. A system like this could be invaluble in 'zero knowlege proxying' networks I wonder if it could be implemented into Ants. The winny sourcecode is floating around the Winny and Share networks .Most of the Winny plugin developers have moved to Share.
Anyone want to make a Japanese translation for Ants LOL.

[tsafa1]

I think, but i'm not sure, that the swarming should help some of the speeds concerns for Ants. if the overhead gets too much people will break off into their own chatroom/private networks and no way to stop them. Ants will connect to anyone in same chatroom who is running ants.

Ants and mute could never share the same network because Ants uses end to end encrytion and mute does not.

Winny does not use the middle-man proxy scheme that ants and mute use. winny uses a file chach method. In winny, your share files are randemly uploaded and stored on other nodes to be downloaded at any time. users do not know what is shared on their cache direcory. This is how anonymity/denyability is provided by winny.

The winny methode could be added to mute. As files are proxied throught the mute nodes they could also be stored so other people could download information from one of the proxy nodes rather then have to go back to the source. This would save considerable bandwith. This would only work because mute does not have end to end encryption and any node can access the information in another node.

This method could never work on ants because in end to end encrption only one node has key to see the contents of the transfered file. So in ants case, you would be collecting useless garbage that can't be reused.

So we can see here that mute definelty has the ability to conserver bandwith. We do not know for sure how ants will perform in a more populated network situation. We do know that if it gets too crowded people can easily set up smaller networks.

[AussieMatt]

Clustering is only to get people of simmialar interests together just like grwens plan to add keys and create groups in ants clustering also can help localise nodes ..
People enter a keywords like 'punk' + 'hardcore'+' mp3' and the system would look for people with similar interests. So in your case tsafa we could use 'porn'+ 'lesbian nuns '+ 'avi' and it would find pervets like yourself automaticly:ass .
Clusterisation is a search function and has nothing to do with the file transfer in Winny so somthing similar could be implimented in Ants .It will help find users like a genre chanel in soulseek for example .

[ABC_thellookoflove]

some say ants and mute cannot scale.
i think ants with its partial swarmign over bittorrent and the big hash index as well remote has a good change to finde the wanted media, if it is a popular released media, so all 10000 usersd wanting the same bittorrent released file inside ants, will find enough sources to swarm.

Maybe a bittorrent client is as well implementing ants protocol, then the whole second generation swarming is as well possible over the 2. gen app for ants users.

Then scaling is no problem and the more users use ants, then it is as well scaling and searching.

Mute... umh... has no swarming, has no bittorrent, is using dangerous ip revealing webcaches, is has no end to end encryption and is this way unsafe and each proxy couidl eb read by isp !!! so very dangerous and mute has even less media and no good remote /local hash indexing machine. as well the protocol is not fast enough, because torrent ha sbetter speeds. so i vote for ants, though, mut is more popula rand has a btter gui and c++ is quicker for the user (longer to debuugg for the developer) than interpreted java. Though java is the future.

So... ants is better than mute and jetiants.tk has great perspectives to scale,

But the users will come only, if there is a board linking to ants as a recommended app and if there is a torrentapp making a swamring with ants possible.

Maybe antzureus. :tol

[Hornet]

I now think that Ants and other P2P2P networks can scale if the average number of hops for file transfer is kept to a minumum.

Since the introduction of random walkers on ANts download speed has increased significantly.

This is probably due to starting point for file transfer being closer to the source and fact that user who are likely to share are clustering together.

This makes the layout of the ANts network as a "small world" or "Power Law" network. These have been shown to scale.

Also there are potential future updates:

I predict that in future "random walkers" will be extended to offer users a choice between slower fully anonymous downloads, faster less anonymous using one hop proxy and faster still not anonymous using direct connection. Users using direct connection could form trusted private groups by exchanging certificates. ANts will then be suitable for all file sharers in competition with other 2nd gen networks and will beable to scale to millions of users.

This is my (Hornet's) opinion only and does not reflect the opinion of the developer.

Hornet

[ABC_thellookoflove]

we need a protocol release of a ants DNA library End January, there are already developers waiting, which want to re-code it in c++

[Hornet]

Hi, ABC but I have to disagree -

ANts is opensource so the source code is available on Sourceforge. If you want to use it just take it and use it.

Also, ANts in Java does work; like Azureus in Java works; like Limewire in Java works.

Sure DC hub applications have been coded in different program languages like DC ++ in C++ but that it is up to the person coding it.

The great thing about Java is that it is easy for non-programmers to read.

Have a look at the code you might be surprised.

Anyway, a major upgrade to ANts is in the pipeline to extend its use by giving users the choice between speed and anonmity and anything in between.(My opinion not developers)

Peace

Merry Xmas

Hornet

[tsafa1]

winny is "anonymous" but fast too, ant's wouldn't be that bad if gwren would rework the connection mechanism ... it would probably be cool if gwren (ants) and jason (mute) would work together so they would be able for sure to create something useful

You touched on something that has great potential. Three seperate issues here regarding Ants, Mute, and Winney. Lets break down a few things. Ants and Mute are anonymous because of the ad-hoc (middle-man ) transfers. Both have point to point encryption but Ants has the additional end-point to end-point.

Winny is anonymous because it uses a file cache methode. (NOT middle-man). On winney your transfers are direct. That is why they are faster. What Winny does is it randomly uploads files out of your share directory and saves it into a secret un-accesable directory on other people hardrives. That directory also becomes a shared directoy. Meanwhile you are also storing other peoples files, without knowlege, on your harddrive. You have no resonable way to find out what those files are. So now when you download you do not know if you are downloading out of the shared directory or the secret cache directory. Likewise when you upload, you are uploading out of your shared files directory and the cache directory. This basicaly gives you some level of denyability. If sued you would try to defend yourself by saying files came out of cache you had no idea about.

Now here's the cream. The winney methode could be implemented into Mute. You are passing along files for other people anyway, It would not take much to save some of that data in a directory and share it. It would give mute an additional level of denyability plus it would increase the content in the network and make it more available.

This file cache method can never be added to Ants because of the end to end encryption. On ants only two nodes have the key to lock and unlock data. The original source and the final destination. On ants file cacheing would mean storing information that no other nodes could ever use. On mute anything that you store can be used by any other node.

So while ants is more secure because of the end to end encryption. Mute can use its lack of end to end encryption to add another level of denyability via file cacheing.


note: thanks to the modes for lifting the ban on me.

[Hornet]

This file cache method can never be added to Ants because of the end to end encryption. On ants only two nodes have the key to lock and unlock data. The original source and the final destination. On ants file cacheing would mean storing information that no other nodes could ever use. On mute anything that you store can be used by any other node.

So while ants is more secure because of the end to end encryption. Mute can use its lack of end to end encryption to add another level of denyability via file cacheing.


note: thanks to the modes for lifting the ban on me.

Welcome back tsafa1.

However I have to disagree with you.

File cacheing is perfectly posible with ANts. The torrent systems relies on it!

However, the only peices that are cached are complete chunks. That means complete chunks of incomplete files are shared. So end to end encryption does not limit cacheing unless you wanted to share incomplete chunks. :)

Also, note end to end encryption has a big advantage in that two users conected securely, can choose to exchange IP addresses securely down an encrypted channel.

These IP addresses could then be used as trusted IPs in the "random walk" node discovery process.

Each user can choose what IP address to send or not send and whether to use recieved IP addresses from settings.

For example, an user could send the IP address of its neighbour node that it is connected to. The user receiving this would then connect to that neighbour.

This would then be a fast one hop proxy connection.

If the IP address sent was the users own IP then it would be a very fast direct connection.

If no IP was sent then it would be a slower fully anonymous P2P2P connection.

Neither party would know if the other had sent their own IP or the IP of a near by or connected neighbour to act as proxy for the transfer.

Using this method you can make direct, proxy or near by node connections with ANts.

So transfer speeds will be as fast if not faster (because of torrent technology) than 2nd generation P2P clients.

However because each user can decide what IP address to exchange securely or decide not to exchange IP addresses at all then the level of anonmity and transfer speed would be decided by each user.

This is an extention to Gwren's "random walk" node discovery algorithm that does not change the ANts protocol that should be implemented in a forthcoming release of ANts. Gwren has all the details.

Note - this has not been agreed fully yet apart from the implementation for the first part of the algorithm for random walk (using random IP addresses) but I'm sure the full algorithm will be in the next big release of ANts.

Also, note that if a user did chose to give out their IP address over a secure connection then he could restrict access to that IP address to only those users who he had exchanged certificates with (a private group form outside of ANts), like WASTE.

So ANts could potential operate like a combination of WASTE, emule, Bit Torrent and MUTE :) As fast or slow as users want and withas much anonmity as users want. Bearing in mid the there is a trade off of anonmity for speed.

This is probably months away (but you never know given how fast Gwren works) but it will be good when it gets here.

Merry Xmas

Hornet
from Springfield, Hackney

[ABC_thellookoflove]

there is development speed, because mute and ants are in competition.
Ants has a media-cache, the partial of the requester (not at the overhead in the middle), The more users will come, the more is this FORCED partial filesharing working very well like in edonkey.
Support ants. Support ANTzureus, then in edonkey, shareaza AND bittorrent seeded Torrents will be available as well in Ants. One downloader in ANTzureus will make the file available in ants, anywhere from where it comes. And partials in ants can spread. No cache needed. Only seeding and swarming should be in ANTzureus hybrid with bittorrent.
MUTE and WINNY are not anonymouse, even dangerous, becaus eif you share yopur IP or Bandwith with others, the ISP should not be able to make YOU responsible for the mediatransfers and actions of others. This is only with end to end in ANTS given! MUTE is open readable postcard others write for you !!! Quite dangerous!

[ABC_thellookoflove]

@ hotnet

trusted buddies are in ants not quite established at now.
We need more jeti integration, then we can use trusted local IP cache exchange as well with jeti-strapping.

Hope hornet p2p works on a better integration of jeti. I want

- connected trusted buddies
- trusted buddies
- Buddies

as categories in the jeti budyylist.
The trusted peers box then has to be deleted and appears in the jeti tab.

[tsafa1]

However I have to disagree with you.

File cacheing is perfectly posible with ANts. The torrent systems relies on it!

However, the only peices that are cached are complete chunks. That means complete chunks of incomplete files are shared. So end to end encryption does not limit cacheing unless you wanted to share incomplete chunks. :)

Also, note end to end encryption has a big advantage in that two users conected securely, can choose to exchange IP addresses securely down an encrypted channel.



The information i posted came from my discusion with GWREN. I do beleve that winney caches partial files and not necesarily the whole file (if that is what youe mean).

I do believe that end to end encryption is better, even if a bit of overkill. But my thought has always benn not to implement it into mute. no sence in having two identical anonymous p2p programs. rather i would prefer for mute to remain non end to end encrypting and try to expand into other areas like file cacheing since it seems better suited for it. This way anonymous p2p can go down another path and we can see how that develops. Everything is still experimental :-)

[Hornet]

Quote form Gwren below http://sourceforge.net/mailarchive/message.php?msg_id=10604690 on


ANts P2P Ad-Hoc Network Scalability

I want to make clear some point about scalability in ANts.

Being near to a source doesn"t mean necessarly transfer files faster


Making lot of connection could help in some cases, but has also many
drawbacks, that is slowing down your node and decreasing the percent
total/own traffic


Being far from a source, can in general speed up the transfer process cuz
of the swarming system


The problems of scalability in ANts are not related to the distance
source-destination, infact the increase of users is related to this distance
in a logarithmic way and this means usually good scalability performances.


Major issues regard the total amount of bandwith avaiable, so actually
the matter is "having enough UP bandwith to support a determined amount of
users", not "creating a proper configuration to let users be near
each-other"





Explaination:


1.If you are near to your source, but your source is a kind of supernode,
that is a node with many connection and lot of traffic, probably you will be
required to route lot of packets that are not destinated to you

--> you download and upload slower than in the case where you are far from your
source - in a net location with lower traffic

--> this is already implmemented cuz when you do connections you keep only the neighbours with lowest ping... so low traffic neighbours!).


3.If you are far from the source,

if your source has a lot of traffic and

if others downloading the same file are far eachother,

everytime the source sends packets these packets will be exchanged easily among downloaders, because probably almost some of these downloaders will be linked to low
traffic areas and will spread packets in an easier way than the original
source does.

So better an omogeneus and distributed localization of the
downloaders in the whole net, this also makes easier spreading the file into
the net, because after a while every node will be near to almost a source of
the file.


4.The maximum distance source-destination in a net AS BIG AS THE CURRENT
ED2K NET (2 million users), is 10 hops

if every node has a mean of 4 connections, this is a mathematical MAXIMUM (log(base 4) 2^20 = 10),

usually you will be nearer to your source,

so you see the distance will not be a critical factor,

cuz usually a message will do 3/5 hops to reach a source (even with 2 million users!).

This is the reason why a procedure to get nearer and nearer to the source is USELESS,

you are already near enough to your source simply making some random connections to the net (say 4).

So the critical factor is the bandwith!

As the nodes are so near each others, this mean the there will be a HUGE traffic all around the net,

so even if you are neighbour of your source, you will have to route a big amount of traffic
that is not destinated to you, and you will eventually download at the same
rate you would download if you were 3/4 hops away,

as I say also it is likely that if your source is a high traffic source, you will download
slower than in the case you are far from it (in a place with less traffic),

because in the second case, you could dedicate more bandwith to your own
downloads from other sources.

So the critical factor is not the source proximity, but the amount of traffic that your neighbours produce!

If you connect to neighbours that produce low traffic you will download faster even
if you are far from your sources, and also you will contribute to balacing
traffic!


Hornet

[CactusChris]

BEWARE - Unformatted thinking going on below!

I see a different issue regarding scalability - but perhaps that is just my view of the network...
Think of the network now and on an initial startup random nodes connect giving an interlacing pattern. This is not a bad way to have things to start with, but as the user base grows the most efficient topography is to have many small networks that connect to each other and through each other via 'supernodes' - but supernodes can be a means of attack.
Gwren's method of discarding nodes that are just sending proxied data (ie not for the current node), and randomly connecting to another node in the hope that this will reduce the amount of proxying going on is a good one in a small network - the problem is that statistically it quite quickly fails as the number of nodes that are available increases and the likelyhood of finding a better node by random selection drops off.
What it needs to do is to try to collect to nodes in the vicinity of the data that is required - and in an anonymous network that is not possible. Hornet's idea of handing over IP addresses on request might solve this - but will allow the anonymous part to be broken.
A better way might have to be to have a 'group' number assigned on startup and split the IPs into groups - then when discarding a node the search for a new node that will provide the data can be directed in some way at the group from where the data comes from (need group number in the block header?). If the groups are large enough (ie > 50) then the anonymous part is retained and the 'step closer to the source' also is satisfied. I'm not sure what happens when files are required from many groups...help me out here with some thinking please!)
For the minute we are one group - so no problem - but the escalation could kick with only a few more users (sorry I have not modelled it - the idea alone hurts my brain - but it is possible i'm sure).

As usual - stands back to be told it is all wrong.....

Best regards
Chris

[crackerjacker]

anoymous proxy nodes is way different from a regular proxy.
a regular proxy are ip address ranges which can be free or not, which keeps logs, altho if u use foreign proxies you dont have to worry about those foreign proxies from revealing the ip range of those people who connected to them so a regular foreign proxy is safe.

unfortunately its way different with proxy nodes because with a proxy node they are relatively sending the data on behalf of another person, hence that ip address can be logged, and that person relating the data on bahalf of the other users are responsible for the data.

this is my opinion and is concise and accurate as i deem it to be.
cheers

[tsafa1]

anoymous proxy nodes is way different from a regular proxy.
a regular proxy are ip address ranges which can be free or not, which keeps logs, altho if u use foreign proxies you dont have to worry about those foreign proxies from revealing the ip range of those people who connected to them so a regular foreign proxy is safe.

unfortunately its way different with proxy nodes because with a proxy node they are relatively sending the data on behalf of another person, hence that ip address can be logged, and that person relating the data on bahalf of the other users are responsible for the data.

cheers

You have no controll over what those foreign proxies may or may not do. They may very well be set up as a honeypot by a hostile organization to trap people. Or they may be bribed to record and report infromation. Some may be honest, some may be not, but its a greedy world.

As far as proxy nodes on ants, it is imposible to determine where you are in the chain. you may be the 5th man in a 10 person chain. It is unlikly that you can be held liable for proxying something that you have no knowledge of. ISP's have gone to great lenths to establish that they are not responsible for what people send through their networks. Laywers have stated that the defense that applies to ISP's should also apply to individuals. I will post the quote if you want.

[Hornet]

BEWARE - Unformatted thinking going on below!

I see a different issue regarding scalability - but perhaps that is just my view of the network...
Think of the network now and on an initial startup random nodes connect giving an interlacing pattern. This is not a bad way to have things to start with, but as the user base grows the most efficient topography is to have many small networks that connect to each other and through each other via 'supernodes' - but supernodes can be a means of attack.
Gwren's method of discarding nodes that are just sending proxied data (ie not for the current node), and randomly connecting to another node in the hope that this will reduce the amount of proxying going on is a good one in a small network - the problem is that statistically it quite quickly fails as the number of nodes that are available increases and the likelyhood of finding a better node by random selection drops off.
What it needs to do is to try to collect to nodes in the vicinity of the data that is required - and in an anonymous network that is not possible. Hornet's idea of handing over IP addresses on request might solve this - but will allow the anonymous part to be broken.
A better way might have to be to have a 'group' number assigned on startup and split the IPs into groups - then when discarding a node the search for a new node that will provide the data can be directed in some way at the group from where the data comes from (need group number in the block header?). If the groups are large enough (ie > 50) then the anonymous part is retained and the 'step closer to the source' also is satisfied. I'm not sure what happens when files are required from many groups...help me out here with some thinking please!)
For the minute we are one group - so no problem - but the escalation could kick with only a few more users (sorry I have not modelled it - the idea alone hurts my brain - but it is possible i'm sure).

As usual - stands back to be told it is all wrong.....

Best regards
Chris

I agree but rather than grouping ranges of IPs together I would just extend the node's random walk so that it used IP addresses obtained from "IP messages" from uploaders as well as IP addresses that were collected during the random walk. Node would then radomly select from the combined list (IP address messages and "random walk" IP addresses).

By default uploaders would send out a message with a random IP address from IP addresses found during random walk.

This would have same effect of making a big network into a small one, as users would be brought RANDOMLY closer together around content.

Users would RANDOMLY cluster slightly preferrentially nearer content without loss of anonymity because the process is still random neither downloader or uploader know what IP they are going to connect to in random walk.

All that is known is that they have A CHANCE to get near to an UPLOADER and vice versa.

Also, it would help if the random walk was limited to say 2/3 hops in every direction.

So BIG net becomes SMALL net :)

ANts P2P would then scales by partitioning the overall network into smaller anonymizing cliques (groups of nodes that share some content and their random walk neighbours).

This decouples the anonymization protocol from the size of the overall network, while it provides sufficient participants in an anonymizing clique to provide effective anonymity.

I think you've cracked it Cactuschris.


:upside

[crackerjacker]

hmm a nice sniffer program is all it takes to determine ip address originality
*woot*

[tsafa1]

hmm a nice sniffer program is all it takes to determine ip address originality
*woot*

please point one out to me and tell me how to use it. i will immidietly point it out to Gwren. The man can only counter threats that actualy exist. If someone does actualy write something that tracks ants in the future, and i'm sure someday someone will, Gwren stands ready to counter that threat. The man puts out almost a new update every day, I don't think he would put his hands in his pocket and do nothing.

We have to focus on the situation as it presently exists. It is posible that copywrite laws will be ruled unconstitutional sometime soon too and I can go back to using kazaa-lite.

[AussieMatt]

CJ try Tcp Dump or WinDump and Ethereal with ants first you cant deycrypt the data in the packet becuse its its encrypted look at the strings and the IP remains that of your nighbors even if you are downloading go give it a try and come back with your findings .We all know you can find the IP of others on the network its a no brainer but can you determine what they are sharing or where that data originating from .If you can crack Ants you probably crack a few other systems that use encryption .

[shawners]

ITS not fanboying if its posted in the ANTS Forum.. Please read above. If any p2p that comes out would take away such rubbish.. take for instance abc torrent and a few others... You can choose to cut it off when your away or when your not by your pc.. As well as every program now can limite your download and upload.. if it does'nt have the feature, their are bandwidth monitors galore to let you cap it all off.. Slowing everyone down to a crawl. Even yourself.. Imagine waiting in queue for a long time to get a file, and everyone is downloading at 3kbs or not even upping more then 1kbs.

[Hornet]

Anonymizing Cliques, ANTs/MUTE Scalability and Random Walk

An anonymizing clique decouples the anonymization protocol from the size of the overall network, while it provides sufficient participants in an anonymizing clique to provide effective anonymity.

"Random walk method of discarding nodes that are just sending proxied data (ie not for the current node), and randomly connecting to another node in the hope that this will reduce the amount of proxying going on is a good one in a small network - the problem is that statistically it quite quickly fails as the number of nodes that are available increases and the likelihood of finding a better node by random selection drops off."(1)

However, this can be fixed by using anonymizing cliques.

An anonymizing clique group for a user is made up of its immediate neighbours and their neighbours. Users select its size, 0 hops - user only, 1 hop - user and immediate neighbours, 2 hops - user, immediate neighbours and their immediate neighbours and so on.

Each user is part of an anonymizing clique group. Each group is identified by an IP address selected at random from group members.

When a user (A) wants to UPLOAD or DOWNLOAD from another user(B) they anonymously exchange messages, containing their anonymizing clique identifier (random IP address from their group), with each other.

Each (A and B) then use the received anonymizing clique identifier as the START POINT for a "random walk" that corresponds to the size of their own anonymizing clique. They then connect to the resulting IP address. (This is part of bootstrapping to net a separate process to routing messages and files)

In this way "random walk SCALES. No matter how big the network gets it will always find a NEW peer near to content WITHOUT A LOSS OF ANONYMITY.

"Major issues regard the total amount of bandwidth avaiable, so actually the matter is "having enough UP bandwidth to support a determined amount of users""(2)

This is important as, NETWORK CAPACITY depends on bandwidth available. Bandwidth available can either be increased by users donating more bandwidth to the network OR by THE NETWORK IN TOTAL using less bandwidth to route transfers.

"As an example, we can assume that a transfer is worthwhile as long as it is coming in at over 5KB/second. If we assume that everyone has a cable modem with a tight upstream bottleneck, then each node can handle relaying or uploading about three files simultaneously. Next, we can assume that each DOWNLOAD PASSES THROUGH FOUR INTERMEDIARY NODES ON AVERAGE. If we have a network of 1,000 nodes, then we can support at most 600 simultaneously downloads at decent rates — each download taxes the upstream bandwidth of five nodes, and each node can handle being taxed by three simultaneous transfers.

Of course, these calculations change as the assumptions change, but we have just laid out assumptions that would suggest that MUTE could support 60% of its users downloading one file each at worthwhile rates. As the percentage of downloaders increase in this network, the download rates would decrease throughout the network."(3)

The capacity of a NETWORK is directly proportional to the average number of hops taken to route transfers between users. Reducing this average increases network capacity. In Jason's example above if the average number of hops (intermediate nodes) were HALVED to two then the NETWORK capacity would DOUBLE.

Using a random walk based on anonymizing cliques will reduce the average number of hops for THE NETWORK so increasing NETWORK capacity WITHOUT A LOSS IN ANONYMITY.

Sure connecting nearer to content will not result in faster transfers for SOME USERS for the reasons Gwren described in his "ANts Scalability" post(2) BUT the CAPACITY of THE NETWORK overall will INCREASE as content is moved nearer users.

Freenet uses this concept in a different way rather than reconnecting users to be nearer content it actually moves content.

"You could look at it like an ant colony where instead of food you have pieces of information, and instead of ants you have requests, which travel around this network.

Freenet, when you request a piece of information on Freenet, you ask your local Freenet node for that information. If it has the information itself, it will obviously return it to you.

If not, it will forward that request on to another node that is more likely to have that information - and nodes in the network actually learn with time how to better route information through the network - so they additionally move information closer to where the demand for that information is, so that when you request a piece of information, immediately after you requested it a copy of that information will reside on your computer and the computers close to you for a short amount of time.

If you or other people close to you then request that information, they will receive that information immediately. So this is really the way that it dynamically moves information closer to demand."(4)


Hornet :upside :upside :upside


(1)CactusChris (http://www.zeropaid.com/bbs/showthread.php?t=24834&page=3&pp=15)
(2)Gwren - ANts Scalability post (http://sourceforge.net/mailarchive/message.php?msg_id=10604690)
(3)Jason Rohrer the developer of the original ad hoc ants network application MUTE (http://www.onlamp.com/pub/a/onlamp/2004/08/12/mute.html?page=1)
(4) Ian Clarke (http://www.openp2p.com/pub/a/p2p/2000/11/14/ian.html?page=2)

[ABC_thellookoflove]

this is a good concept and means exaclty what I wanted to suggest with the "long distance flight to the ants hill" by direct IP transfers and searches. Otherwise ants will NOT sacale. (tralawney graphic).

Every ants node decides how big the circle of the neighbourhood is,
One hop, two or three.
ONE direct IP is choosen out of thos clique (though this means, that clique members know all the IP adress of neighbours!?)


Why then only transferring from direct IP to direct IP withing clique member and clique member.
(my term for Clique was "CLOUD" or ants "HILL").

My suggestion is, that the CLIQUES or HILLS or CLOULDS have as well an OWN DHT, so the remote library index is available.

Then you can use the gnutella 2 protocol to seach the hill-cloud in europa and transfer search results from the hill-cloud to australia.

Withing the Hill then the anonymous random walk is done, in both hills.


This is what I meant with - "EACH HILL NEEDSA QUEEN". this is the clique member with a direct IP transfer to any other Queen od any other hill over the see.

But this transfer is not a direct IP-to-IP transfer, the QUEEN shoudl know as well all remote shared library data. this data then could be search by the gnutella 2 protocol.

this means to use gnutella 2 for the long distance flight to the ants hill and then use the ants pheromones within the ants hill.

One is claer: The pheromones of europes ant hill are not smelling / stinking the long way to ants hill in australia.

Though, Gwren says 20+39**2*2 = all search results are available within 2 hops.

This is not right, and we need a plane carrier for the ants queen.

[crackerjacker]

Of course I dont have no control over the foreign proxies, that is why its not as safe either. But hey those are chances u take either way.

well I do have to state its possible to obtain ip range of whose sending u the data of a file via a p2p program.
there is plenty of software tools to use to get this information.

[tsafa1]

well I do have to state its possible to obtain ip range of whose sending u the data of a file via a p2p program.
there is plenty of software tools to use to get this information.

Please give us specifics so that we can investigate any posible threats to individule denyability.

[CactusChris]

Cliques sounds good - there are several issues that will need to be solved, like how to move cliques when the data source that originally drew you there dries up.
This is just another unformatted view written as a process(for what it is worth..). Assume for the minute that the administration of the cliques is solved - this could be done via a number of IRC channels or by some kind of temporary web cache - but the security issues are serious and need solving (ie a map of all ips in a clique is dangerous information if abused).

I join ANts - any clique - but now I'm in - first ip connection I get that is my clique. I do a search for files that I want and find a source (search goes beyond local clique). I now broadcast a request to the entire network for an IP on that clique to connect to me (note - I broadcast *my* IP). This is just like current startup in a way.
Now I get a response and connect to the new clique. I stay there by connecting to more IPs in that clique by continuing to braodcast a request for connections until all but one of my connections are filled (I can discard the original node at this stage - it is in the wrong clique for me and has no files for me). With the remaining available slot I randomly try to join another clique - no need to broadcast it - just connect to a random node. This node is queried for files that I want and if none appear then it is I disconnect from it and try another - this means that about 1/6 of my nodes is in the process at all times of walking the network looking for best fit on the files availablity - while 5 are transferring data to and fro.
.This gives the network a good degree of connectivity and stops it fragmenting into isolated subnets while keeping the cliques contained.
If I get no incoming data for ~10 mins I move cliques by dicarding current clique nodes (one at a time) and moving to my single connected node that has access to another clique and the process continues until I find a clique that has data I want.
I have only thought this out from a download perspective - need also to think what happens if I am uploading to my current clique - oh what the hell - sod 'em - if there is nothing I want on this clique I'll move ;-).
So I'm mostly busy in a clique downloading - while I have on slot walking the network looking for a better clique to move to.
Initial chaos settling in to an ordered process - the dynamics are important to get at the right level or we will all just wander randomly round connecting - and when we find a good clique the source data could well move away - so stability is also needed.
The size of a clique is also important - a clique should not respond if it is already at max size - oh damn - how do we control that? Or do we need to? perhaps it becomes self limiting - needs thinking about.

Hmm - well I am at least being a constructive thinker even if it is all full of holes.

[infringer]

"We have to focus on the situation as it presently exists. It is posible that copywrite laws will be ruled unconstitutional sometime soon too and I can go back to using kazaa-lite."

Unconstitutional sounds like something to push for unconstitutional copywrights but I believe it'd take a relitively large case to deem copywrights unconstitutional though I am sure there is some ways which this is true and copywrights are unconstitutional in many ways.

I think the more lawsuits of infringement filed the more the government will look at the current copywright system as outdated or flawed.

AntsP2P has came a long way and has a decent amount of support. As far as I can tell so far it is anonymous. I cant think of a way that you would be able to sniff to turn results of who is sharing and downloading what sniffing basically is a way to figure out if there are ports open to exploit so there would have to be a way to exploit the open ports to figure out who is sharing what and show return paths showing the full routes of sent information this seems like it would be a tough task and first off someone would have to have an IP to start at or know the IP starting and ending destination I dont believe that this is likely to happen anytime soon.

But what do I know I aint no hacker or have no need for sniffing ports never really done anything of the sort.

I dont think that there is even a case if they cannot pin an IP to a specific file simply routing data on a network blindly is not illegal currrently I think its a fairly safe and fairly secure network and now offers the 1,2 punch more effectively.

-infringer-