[PATCH REQUEST] Variable ports (205BTC reward)

theymos

administrator

Activity: 5166

Merit: 12850

Quote from: dsg on December 25, 2010, 08:09:36 PM

Interesting, is this by design or a bug?

It's by design. Here is Bitcoin choosing which peers to connect to:

Code:

// Randomize the order in a deterministic way, putting the standard port first
int64 nRandomizer = (uint64)(nStart * 4951 + addr.nLastTry * 9567851 + addr.ip * 7789) % (2 * 60 * 60);
if (addr.port != GetDefaultPort())
nRandomizer += 2 * 60 * 60;

dsg

jr. member

Activity: 37

Merit: 2

Quote from: theymos on December 24, 2010, 04:49:20 PM

Quote from: wumpus on December 24, 2010, 09:21:54 AM

On a related note: from discussion on IRC I understood that the peer exchange protocol somehow doesn't have support for alternative ports. Does this patch work as advertised at all?

The protocol supports alternative ports just fine, though you won't receive incoming connections because Bitcoin prefers not to connect to peers that are using non-standard ports.

Interesting, is this by design or a bug?

I think it will be imperative for bitcoin to randomise port and use encryption, in order to avoid being blocked by firewalls or DPI boxes. Hopefully this will be implemented before it's needed.

theymos

administrator

Activity: 5166

Merit: 12850

Quote from: wumpus on December 24, 2010, 09:21:54 AM

On a related note: from discussion on IRC I understood that the peer exchange protocol somehow doesn't have support for alternative ports. Does this patch work as advertised at all?

The protocol supports alternative ports just fine, though you won't receive incoming connections because Bitcoin prefers not to connect to peers that are using non-standard ports.

wumpus

hero member

Activity: 812

Merit: 1022

No Maps for These Territories

Quote from: mizerydearia on December 24, 2010, 08:11:45 AM

This patch doesn't work anymore. Is this still necessary or has it made it into official svn?

Nope, it's not in official SVN yet.

On a related note: from discussion on IRC I understood that the peer exchange protocol somehow doesn't have support for alternative ports. Does this patch work as advertised at all?

mizerydearia

hero member

Activity: 574

Merit: 507

This patch doesn't work anymore. Is this still necessary or has it made it into official svn?

mizerydearia

hero member

Activity: 574

Merit: 507

original post edited to include link to patch.

jgarzik

legendary

Activity: 1596

Merit: 1091

Patch updated for latest SVN.

mizerydearia

hero member

Activity: 574

Merit: 507

Quote from: Gavin Andresen on September 21, 2010, 09:31:38 AM

Quote from: nelisky on September 20, 2010, 09:59:54 PM

no reason to change that, as other clients only try to connect to 8333, afaict. IRC only advertises IP, right?

No, both IP and port are encoded in the #bitcoin IRC usernames (see the EncodeAddress/DecodeAddress routines in irc.cpp).

(so mizerydearia: no need to do what you done did...)

Mm... On a slightly unrelated issue. Since it is possible to detect majority of all nodes in the p2p network by visiting the bootstrapping irc channel, it seems fairly easy to determine where exactly all the nodes are in case any attempt to disconnect Internet or seize hardwares ever occurs. Perhaps another thread should be used to discuss this.

nelisky

legendary

Activity: 1540

Merit: 1001

Quote from: Gavin Andresen on September 21, 2010, 09:31:38 AM

Quote from: nelisky on September 20, 2010, 09:59:54 PM

no reason to change that, as other clients only try to connect to 8333, afaict. IRC only advertises IP, right?

No, both IP and port are encoded in the #bitcoin IRC usernames (see the EncodeAddress/DecodeAddress routines in irc.cpp).

(so mizerydearia: no need to do what you done did...)

So I could use -inboundport= and use that instead of DEFAULT_PORT, or if 0 disable inbound completely like I do now. Hmmm, I feel a patch to your patch coming.

Gavin Andresen

legendary

Activity: 1652

Merit: 2216

Chief Scientist

Quote from: nelisky on September 20, 2010, 09:59:54 PM

no reason to change that, as other clients only try to connect to 8333, afaict. IRC only advertises IP, right?

No, both IP and port are encoded in the #bitcoin IRC usernames (see the EncodeAddress/DecodeAddress routines in irc.cpp).

(so mizerydearia: no need to do what you done did...)

mizerydearia

hero member

Activity: 574

Merit: 507

Quote from: nelisky on September 20, 2010, 09:59:54 PM

no reason to change that, as other clients only try to connect to 8333, afaict. IRC only advertises IP, right?

For IRC I set my user name to 8332 and my real name to 8333 as per server connection configuration and then connected.

Code:

/whois necrodearia
[necrodearia] ([email protected]): 8333
* [necrodearia] #bitcoin-dev #bitcoin
* [necrodearia] peacock.heliacal.net :Chicago, IL USA
* [necrodearia] idle 00:00:09, signon: Tue Sep 21 07:46:38
* [necrodearia] End of WHOIS list.

Using this method, it is possible to embed port numbers that a client is using into their IRC connection so that ports are not restricted to 8332 and 8333. I suggest implementing this or a related implementation into a future version of Bitcoin.

Satoshi o/

nelisky

legendary

Activity: 1540

Merit: 1001

I know my usecase (multiple bitcoin clients on the same server) is not the same thing that is being solved by this patch, it does fix most of it. The only thing remaining is to prevent binding to 8333 (no reason to change that, as other clients only try to connect to 8333, afaict. IRC only advertises IP, right?).

I've patched my client with this simple change:

Code:

--- a/net.cpp
+++ b/net.cpp
@@ -1236,6 +1236,9 @@ bool BindListenPort(string& strError)
memset(&sockaddr, 0, sizeof(sockaddr));
sockaddr.sin_family = AF_INET;
sockaddr.sin_addr.s_addr = INADDR_ANY; // bind to all IPs on this computer
+ if (mapArgs.count("-disableinbound")) {
+ return true;
+ }
sockaddr.sin_port = DEFAULT_PORT;
if (::bind(hListenSocket, (struct sockaddr*)&sockaddr, sizeof(sockaddr)) == SOCKET_ERROR)
{

so passing the -disableinbound switch makes it not try to bind the 8333 port.

aceat64

full member

Activity: 307

Merit: 102

Quote from: jgarzik on September 18, 2010, 03:43:56 PM

Patch updated for latest SVN. Given recent upstream changes to support binding to any address (0.0.0.0 or '*'), this patch is reduced to adding an option to bind or connect to a non-standard, not 8332 port:

URL: http://yyz.us/bitcoin/patch.bitcoin-bindaddr

I've added the new bindaddr patch to my client.

jgarzik

legendary

Activity: 1596

Merit: 1091

Patch updated for latest SVN. Given recent upstream changes to support binding to any address (0.0.0.0 or '*'), this patch is reduced to adding an option to bind or connect to a non-standard, not 8332 port:

URL: http://yyz.us/bitcoin/patch.bitcoin-bindaddr

jgarzik

legendary

Activity: 1596

Merit: 1091

Quote from: nelisky on September 16, 2010, 01:15:32 PM

Quote from: aceat64 on September 16, 2010, 01:06:50 PM

I've now removed jgarzik's patch from my client in favor of using Satoshi's -rpcallowip setting (since it's in the vanilla svn).

But that doesn't allow separate ports to run multiple clients on the same machine, does it?

I'll update my patch on top of -rpcallowip soonish... The JSON-RPC port is still hardcoded as 8332 in vanilla svn Sad

aceat64

full member

Activity: 307

Merit: 102

Quote from: nelisky on September 16, 2010, 01:15:32 PM

Quote from: aceat64 on September 16, 2010, 01:06:50 PM

I've now removed jgarzik's patch from my client in favor of using Satoshi's -rpcallowip setting (since it's in the vanilla svn).

But that doesn't allow separate ports to run multiple clients on the same machine, does it?

That is correct, but my main concern was being able to connect to the JSON-RPC interface from somewhere other than localhost. Specifically so that I could manage my nodes with phpMyBitcoin.

nelisky

legendary

Activity: 1540

Merit: 1001

Quote from: aceat64 on September 16, 2010, 01:06:50 PM

I've now removed jgarzik's patch from my client in favor of using Satoshi's -rpcallowip setting (since it's in the vanilla svn).

But that doesn't allow separate ports to run multiple clients on the same machine, does it?

aceat64

full member

Activity: 307

Merit: 102

I've now removed jgarzik's patch from my client in favor of using Satoshi's -rpcallowip setting (since it's in the vanilla svn).

mizerydearia

hero member

Activity: 574

Merit: 507

Ah, cool. Thanks for the confirmation.

aceat64

full member

Activity: 307

Merit: 102

Quote from: jgarzik on September 15, 2010, 04:55:43 PM

Quote from: mizerydearia on September 15, 2010, 04:38:02 PM

This doesn't seem to be compatible with Slight change so that JSON-RPC binds to all/any IPs instead of just the loopback.. Can these patches be combined or is one better than the other?

Those two patches attempt similar things, and so should be considered mutually incompatible.

Yup, I've removed my patch, as jgarzik's is better (mine was just a simple hack).

Topic: [PATCH REQUEST] Variable ports (205BTC reward) (Read 10257 times)