port blocking, throttling, and scrambling

[alphabeater]

Originally posted by Scyth
How do you know what IP your gateway peer is at?Who/Whatever gives you its IP can also give you the port number.

as i've said, this could be useful on a network such as kazaa or winmx because everyone can run on a completely different port, and there's no need for anyone (not even a supernode) to tie itself up keeping large lists of them and passing them backwards and forwards to people in complex webs, as they can be calculated on-the-fly by the program itself.

passing everyone's port around with everyone's ip address means that peers have to go around asking other peers which port they are listening on.. and if you don't know which port a peer is listening on, the catch-22 is that it's impossible to ask them.

[db_]

Hi.

People can run whatever port they like, it makes no difference to the operation of the client on the network. If every user on the Kazoo network changed their listening port to a random one, it wouldn't change a thing regarding how the network operates (as far as I'm aware). It'd simply make it more difficult for an ISP to run filters based on ports, there ain't a common port this way.

I use 32200 for WinMX currently, simply refers to the current version number and helps avoid any complications during transfers caused by any common port filters in place anywhere on the network connection between me and whoever. There's no need for me to advertise or do anything special in order to operate using a different port other than to manually change it myself.

If I'm a primary here's what happens...

I start WinMX, it contacts the cache
me:4363 contacts cache:7720

cache:7720 gives me IP: port of a OtherPrimary:6699

me:4224 connects into OtherPrimary:6699
(I'm online with the network now)

Some other user, a secondary (SC) user contacts the cache for a Primary to connect into, the cache responds to the secondary user with it's cached IP:Port of my machine...

SC:4256 contacts Cache:7701
Cache:7701 replys to SC:4256
SC:2432 connects into me:32200

I'm sharing files on the network. A remote user sends out a search request, it hits my Primary (me), I reply with the information to the user requesting results with the file details (name, size, type, etc), my IP, and my listening port to connect into.

The remote user double-clicks the search result, the information contained within that search result directs the user to connect into my IP:Port, and the transfer starts (all going well).

That's it really, changing ports doesn't change anything regarding how connections are made within the network (afaik). It just randomizes the ports that the application uses, meaning an ISP can't place a simple filter on any specifc port number, it wouldn't do anything.

It's important each users port remains static, as many users have routers that need to forward incoming packets addressed to specific ports to the appropriate machine. So, upon installation of the client, it'd be preferable if the port was chosen at that point, from there on the router can be configured according to the port chosen during installation. Any user that can't handle port forwarding would chose the easy option of operating the client in the 'firewalled' mode that doesn't require any static listening ports to be defined or configured. I'm not gonna go into the 'firewalled' way of things, I'll just say it's no substitute for static listening ports and cannot be used unanimously.

enough for now.

dB.

[TankGirl]

A good thread with plenty of ideas and information – thanks alphabeater, db_, Scyth and others!

I think it is a good general approach to make p2p clients as unpredictable and adaptive as possible so that their use would be very hard to track, block or control by your ISP or anybody else. Random port selection from user-defined range is a good first measure against mechanical blocking. Fully encrypted communications between peers would be the next natural step. If your ISP has no way of telling what you communicate through protected pipes with other peers, p2p becomes externally indistinguishable from Virtual Private Networking practiced routinely by many businesses today.

Originally posted by alphabeater
looking at the posts above, an interesting set of problems are posed. a way of calculating a port number is needed which:

- is almost random
- cannot be figured out by a peer's isp
- can be figured out by another peer on the network
- is static for use with routers/firewalls

Point 2 fails on open networks because of point 3: your ISP – just like Hilary Rosen and Jack Valenti – is free to enter any open network as a normal peer and access the same information as any other peers, making possible port-sniffing bots etc.

- tg

[Scyth]

Originally posted by alphabeater
...and if you don't know which port a peer is listening on, the catch-22 is that it's impossible to ask them.

..But if you don't know what IP a peer is at, it's impossible to ask them, too.

Yes, it is necessary to know the IP and port of at least one peer in order to bootstrap yourself onto the network. That information has to come from outside the network. This is normally done using a combination of static files and DNS resolution. Once you're on the network, the IPs and ports of the rest of the hosts become available to you.

[alphabeater]

Originally posted by Scyth
Yes, it is necessary to know the IP and port of at least one peer in order to bootstrap yourself onto the network.

which is easier: knowing a few domains (told to you by friends) and being able to work out their ips and ports from there as a gateway into the network, or having to get both from some kind of host cache (the weak point of gnutella in particular)?

Originally posted by TankGirl
Point 2 fails on open networks because of point 3: your ISP – just like Hilary Rosen and Jack Valenti – is free to enter any open network as a normal peer and access the same information as any other peers

... unless the network is built on a trust layer - encrypted communications as you say, accompanied by users building their own networks of friends (and friends of friends, etc.) instead of having them automatically built for them by the p2p program. this would make it far easier to remove unwanted peers or files from the network quickly.

in my opinion, the future of p2p doesn't lie in huge, global networks, but in smaller, more personal ones made up of friends and interconnected at certain points.

[Scyth]

Originally posted by alphabeater

which is easier: knowing a few domains (told to you by friends) and being able to work out their ips and ports from there as a gateway into the network, or having to get both from some kind of host cache (the weak point of gnutella in particular)?

I've done both (pre-host-cache-gnutella days), and I think that using a host cache is easier. But if you want to get the information from your friends, you can get the ports from them too.

[alphabeater]

Originally posted by Scyth
if you want to get the information from your friends, you can get the ports from them too.

opennap shows how messy this can get - ports can be difficult to remember, and then there's the added disadvantage that many people don't understand what they are or what they're for.

i hear what you're saying, i'm just trying to find a way which means that people don't ever need to worry about ports again (unless they're behind a router/firewall, of course), because the program can do it for them.

[TankGirl]

Originally posted by alphabeater
... unless the network is built on a trust layer - encrypted communications as you say, accompanied by users building their own networks of friends (and friends of friends, etc.) instead of having them automatically built for them by the p2p program. this would make it far easier to remove unwanted peers or files from the network quickly.

in my opinion, the future of p2p doesn't lie in huge, global networks, but in smaller, more personal ones made up of friends and interconnected at certain points.

I agree 100 %.

You are describing features of socially intelligent p2p topology, and I firmly believe that something like it will soon be implemented on decentralized p2p. Once available, group and community tools will make the whole decentralized scene so much more interesting and exciting! There will always be a place for a global and open sharing layer but groups and communities with their internal activities and their mutual interactions will take the game of p2p to a whole new level.

- tg

[JackSpratts]

Originally posted by alphabeater

which is easier: knowing a few domains (told to you by friends) and being able to work out their ips and ports from there as a gateway into the network, or having to get both from some kind of host cache (the weak point of gnutella in particular)?

that's right. easier, but not better. host caches (and host catchers) are the weak point of gnutella. introduced just over 2 years ago to make the system more workable for newbies and the less technically inclined, they showed their disadvantage almost immediately when napster got slammed by the court in july 2000. with everyone suddenly checking out gnutella and using the caches with the same hosts as the only way on they knew how, they started clumping nodes in ever-tighter circles. before host caching, users got their addresses from friends, web pages and ircs in an ever-evolving matrix of different hosts that all but guaranteed ideal dispersal. as a result each host was connected to an average 10,000 nodes in a fairly smooth system wide configuration that resembled a land dotted by small cities and townships interconnected by only a few roads. after host caching some cells dropped down to just a few dozen in size. adding to the problem were host catchers, where a list of known hosts is deposited for reference. this created as gene kan said, “permanent instability in the network as nodes log on and connect to hosts they remember, irrespective of the fact that those hosts are often poor choices in terms of capacity and topology”. it gets worse with a robust client that refuses to release them and it's something that needs to be avoided in a next generation p2p.

as for providing true anonymity, with untraceable downloads from untraceable hosts well, that’s like the holy grail in peer-to-peer applications.

actually, it is the holy grail.

it's one of those things you devote your life to finding but never do.

still, a floating ip is as good a place as any to start. we probably have to protect filesharing just long enough for the riaa to give up or congress to heed the will of the people which might be a while (a long while). but i don’t really think it will be forever even if it’s going to feel like it.

- js.