Re: XMPP connections
Dnia 2013-11-26, wto o godzinie 01:41 -0900, Haider Ali pisze: > Since we know that we can only open 2 ^ 16 = 65536 ports ( connections > ) with a single machine. That's a common myth. Google is your friend: http://www.quora.com/TCP-IP/What-is-the-maximum-number-of-simultaneous-TCP-connections-achieved-to-one-IP-address-and-port """ The TCP/IP standard sets up unique connection identifiers as the tuple of local IP Address, local TCP port number, remote IP address, and remote TCP port number. In your example, the local numbers are both fixed, which leaves approximately 2^32 remote IP (version 4) addresses, and 2^16 TCP port numbers, or an approximate total potential simultaneous TCP connections of 281,474,976,710,656 (2^48, or 2.81 * 10^14, or 281 trillion). """
Re: XMPP connections
On Tue, 26 Nov 2013 at 12:09, Eric Koldeweij wrote: The 65536 port limit is a client limit, not a server limit. A client can not have more than 65536 connections open to any other host at the same time (65536 is theoretical, in reality this number will be much lower). A client can even have more connections to a single server as long as all combinations of local and remote port numbers are distinct. So, the actual (theoretical) limit is 64k^2 connections per unique combination of local and remote IP addresses. Or in other words, it is the combination of local IP address, local port number, remote IP address and remote port number that uniquely identifies a TCP connection and if only one of these four values is different we are looking at two separate connections that can exist in parallel. cu Reinhard
Re: XMPP connections
Hi, On Tue, 26 Nov 2013 at 11:41, Haider Ali wrote: Can anyone let me know that how XMPP handle so many connections. Since we know that we can only open 2 ^ 16 = 65536 ports ( connections ) with a single machine. But i came to know that single xmpp server can handle more connections than 65536. your assumption that there can only be a single connection per port number at a time is wrong. A combination of local IP address and port can be used for many connections at once as long as the remote IP address *or* the remote port number are different between each of them. Server sockets do this automatically with every call to accept(), but for client sockets you have to set the SO_REUSEADDR option to allow a second bind() while socket using the same port number is still open. cu Reinhard
Re: XMPP connections
Hello, A typical XMPP server will open only one port, port 5222. All clients will connect to that port so in theory an almost unlimited number of connections are possible to that server. This is not particular to XMPP but is a basic TCP/IP client/server feature, exactly the same goes for other services for instance a web server. The 65536 port limit is a client limit, not a server limit. A client can not have more than 65536 connections open to any other host at the same time (65536 is theoretical, in reality this number will be much lower). Regards, Eric. On 11/26/13 11:41, Haider Ali wrote: Hi Everyone Can anyone let me know that how XMPP handle so many connections. Since we know that we can only open 2 ^ 16 = 65536 ports ( connections ) with a single machine. But i came to know that single xmpp server can handle more connections than 65536.
Re: jabberd-2.3.0 release
These are the changes I made jabberd-2.3.0/sx/ssl.c 660 - SSL_set_ssl_method(sc->ssl, TLSv1_2_client_method()); 660 + SSL_set_ssl_method(sc->ssl, TLSv1_client_method()); ... 899 - ctx = SSL_CTX_new(TLSv1_2_method()); 899 + ctx = SSL_CTX_new(SSLv23_method()); ... 757 SSL_set_accept_state(sc->ssl); 758 + SSL_set_options(sc->ssl, SSL_OP_NO_SSLv3); El 26/11/13 11:45, Tomasz Sterna escribió: Dnia 2013-11-26, wto o godzinie 07:40 +0100, Christof Meerwald pisze: I tried upgrading from 2.2.17 to 2.3.0 yesterday, but that left me with a broken server. The s2s component now just connects to a remote server, switches the stream to TLS, gets the certificate, disconnects and immediately connects again. I guess the network is not that ready for 'TLS Everywhere' [1] yet. Maybe it is worth releasing 2.2.18 without that change. [1] https://github.com/jabberd2/jabberd2/commit/ad9ead7816
XMPP connections
Hi Everyone Can anyone let me know that how XMPP handle so many connections. Since we know that we can only open 2 ^ 16 = 65536 ports ( connections ) with a single machine. But i came to know that single xmpp server can handle more connections than 65536.
Re: jabberd-2.3.0 release
Dnia 2013-11-26, wto o godzinie 07:40 +0100, Christof Meerwald pisze: > I tried upgrading from 2.2.17 to 2.3.0 yesterday, but that left me > with a broken server. The s2s component now just connects to a remote > server, switches the stream to TLS, gets the certificate, disconnects > and immediately connects again. I guess the network is not that ready for 'TLS Everywhere' [1] yet. Maybe it is worth releasing 2.2.18 without that change. [1] https://github.com/jabberd2/jabberd2/commit/ad9ead7816 -- Tomasz Sterna @ http://abadcafe.pl/ @ http://www.xiaoka.com/
Re: jabberd-2.3.0 release
If you are interested you can try the changes I made in http://suchat.org/sx/ssl.c For protocols TLS v1.0, v1.1 and v1.2. Carlos El 26/11/13 10:11, Eric Koldeweij escribió: Christof, I had the same problem, luckily I ran on a test server. I could not even login with my client. There has been a change in sx/ssl.c line 899. The line now reads ctx = SSL_CTX_new(TLSv1_2_method()); This means that it will support TLS v1.2 only. Connections using SSLv3 or TLS v1.1 and earlier are not accepted any more. There is also another issue that if a secure connection cannot be established for any reason (incompatible protocol or verification failed or similar) it will retry many times in very rapid succession for 10 minutes. You can get the old behavior back by changing the line above back to the 2.2.17 version: ctx = SSL_CTX_new(SSLv23_method()); I think a better solution would be to use the SSLv23_method and disable SSLv3 with an option immediately after: SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3); I have not tested this yet but as far as I can see it will leave you with support for TLS v1.0, v1.1 and v1.2. An even better solution would be to make the SSL settings user-configurable. This is not trivial to do though. Regards, Eric. On 11/26/13 07:40, Christof Meerwald wrote: On Mon, 18 Nov 2013 17:18:07 +0100, Tomasz Sterna wrote: Next jabberd2 release is finally available. Get 2.3.0 release at GitHub: https://github.com/jabberd2/jabberd2/releases I tried upgrading from 2.2.17 to 2.3.0 yesterday, but that left me with a broken server. The s2s component now just connects to a remote server, switches the stream to TLS, gets the certificate, disconnects and immediately connects again. The log file doesn't give any reason for this connection/disconnection loop and it's not clear what configuration settings need to be updated to make it work again (as the NEWS file isn't that helpful). But as there is no delay between the connects/disconnects (and no useful error message), this behaviour might be considered a bug anyway... Guess I'll have to do some debugging and code reviewing in the next few days... Christof
Re: jabberd-2.3.0 release
Christof, I had the same problem, luckily I ran on a test server. I could not even login with my client. There has been a change in sx/ssl.c line 899. The line now reads ctx = SSL_CTX_new(TLSv1_2_method()); This means that it will support TLS v1.2 only. Connections using SSLv3 or TLS v1.1 and earlier are not accepted any more. There is also another issue that if a secure connection cannot be established for any reason (incompatible protocol or verification failed or similar) it will retry many times in very rapid succession for 10 minutes. You can get the old behavior back by changing the line above back to the 2.2.17 version: ctx = SSL_CTX_new(SSLv23_method()); I think a better solution would be to use the SSLv23_method and disable SSLv3 with an option immediately after: SSL_CTX_set_options(ctx, SSL_OP_NO_SSLv3); I have not tested this yet but as far as I can see it will leave you with support for TLS v1.0, v1.1 and v1.2. An even better solution would be to make the SSL settings user-configurable. This is not trivial to do though. Regards, Eric. On 11/26/13 07:40, Christof Meerwald wrote: On Mon, 18 Nov 2013 17:18:07 +0100, Tomasz Sterna wrote: Next jabberd2 release is finally available. Get 2.3.0 release at GitHub: https://github.com/jabberd2/jabberd2/releases I tried upgrading from 2.2.17 to 2.3.0 yesterday, but that left me with a broken server. The s2s component now just connects to a remote server, switches the stream to TLS, gets the certificate, disconnects and immediately connects again. The log file doesn't give any reason for this connection/disconnection loop and it's not clear what configuration settings need to be updated to make it work again (as the NEWS file isn't that helpful). But as there is no delay between the connects/disconnects (and no useful error message), this behaviour might be considered a bug anyway... Guess I'll have to do some debugging and code reviewing in the next few days... Christof
