Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.os.linux.networking > #3424 > unrolled thread

number of simultaneous tcp/ip connections on 32 bit linux

Back to article view | Back to comp.os.linux.networking

Contents

  number of simultaneous tcp/ip connections on 32 bit linux g918273l@gmail.com - 2015-07-27 14:44 -0700
    Re: number of simultaneous tcp/ip connections on 32 bit linux Richard Kettlewell <rjk@greenend.org.uk> - 2015-07-27 23:11 +0100
      Re: number of simultaneous tcp/ip connections on 32 bit linux Bob Martin <bob.martin@excite.com> - 2015-07-28 08:04 +0100
        Re: number of simultaneous tcp/ip connections on 32 bit linux floyd@apaflo.com (Floyd L. Davidson) - 2015-07-27 23:32 -0800
          Re: number of simultaneous tcp/ip connections on 32 bit linux Richard Kettlewell <rjk@greenend.org.uk> - 2015-07-28 09:19 +0100
    Re: number of simultaneous tcp/ip connections on 32 bit linux Jorgen Grahn <grahn+nntp@snipabacken.se> - 2015-07-28 09:15 +0000
      Re: number of simultaneous tcp/ip connections on 32 bit linux Denis Corbin <news@dm3c.org> - 2015-07-28 18:29 +0200
        Re: number of simultaneous tcp/ip connections on 32 bit linux Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-28 12:51 -0400
          Re: number of simultaneous tcp/ip connections on 32 bit linux Denis Corbin <news@dm3c.org> - 2015-07-28 23:27 +0200
            Re: number of simultaneous tcp/ip connections on 32 bit linux Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2015-07-28 18:27 -0400
              Re: number of simultaneous tcp/ip connections on 32 bit linux Denis Corbin <news@dm3c.org> - 2015-07-29 09:18 +0200
    Re: number of simultaneous tcp/ip connections on 32 bit linux Jamma Tino Schwarze <jamma-usenet@tisc.de> - 2015-08-06 10:12 +0000
      Re: number of simultaneous tcp/ip connections on 32 bit linux JT <JT-reply-only@newsgroup.nl> - 2015-08-06 13:31 +0200
        Re: number of simultaneous tcp/ip connections on 32 bit linux Charlie Gibbs <cgibbs@kltpzyxm.invalid> - 2015-08-06 17:40 +0000
        Re: number of simultaneous tcp/ip connections on 32 bit linux Rick Jones <rick.jones2@hp.com> - 2015-08-06 17:04 +0000
        Re: number of simultaneous tcp/ip connections on 32 bit linux Jamma Tino Schwarze <jamma-usenet@tisc.de> - 2015-08-26 13:31 +0000
          Re: number of simultaneous tcp/ip connections on 32 bit linux Richard Kettlewell <rjk@greenend.org.uk> - 2015-08-26 18:33 +0100
            Re: number of simultaneous tcp/ip connections on 32 bit linux Jamma Tino Schwarze <jamma-usenet@tisc.de> - 2015-08-27 14:06 +0000
    Re: number of simultaneous tcp/ip connections on 32 bit linux Dumpsdrive Drive <fromdrive@gmail.com> - 2015-12-19 06:37 -0800

#3424 — number of simultaneous tcp/ip connections on 32 bit linux

Hi All,

I have a specific question on implementing a load balancer or a TCP/IP server program that does TCP/IP.

Since port number is 16 bits, there are a max of only 65536 ports on a single Linux box at any given time.
And TCP/IP needs a port number to talk to the outside world.
1) when a client establishes a connection, an ephemeral port number is chosen.
2) when a server listening on a socket accepts a connection, a port number is assigned.

So in my understanding at any given time only maximum 65536 TCP/IP connections can exist on a given machine.

So how is it that some or most load balancers claim 200,000 or more concurrent connections?

Can someone please explain that?

Also regarding load balancers, once a load balancer has forwarded a request to one of the servers behind it, can the load balancer somehow pass some information to it, that will help the server to respond back to the originating client directly to avoid the latency of sending back the response via the load balancer?

Thanks everyone for your help.
Gargi

[toc] | [next] | [standalone]

#3425

g918273l@gmail.com writes:
> I have a specific question on implementing a load balancer or a TCP/IP
> server program that does TCP/IP.
>
> Since port number is 16 bits, there are a max of only 65536 ports on a
> single Linux box at any given time.
> And TCP/IP needs a port number to talk to the outside world.
> 1) when a client establishes a connection, an ephemeral port number is chosen.
> 2) when a server listening on a socket accepts a connection, a port
> number is assigned.
>
> So in my understanding at any given time only maximum 65536 TCP/IP
> connections can exist on a given machine.

A TCP connection is identified by the source address, source port,
destination address and destination port.  Lots more than 65536
possibilities.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#3426

in 503286 20150727 231134 Richard Kettlewell <rjk@greenend.org.uk> wrote:
>g918273l@gmail.com writes:
>> I have a specific question on implementing a load balancer or a TCP/IP
>> server program that does TCP/IP.
>>
>> Since port number is 16 bits, there are a max of only 65536 ports on a
>> single Linux box at any given time.
>> And TCP/IP needs a port number to talk to the outside world.
>> 1) when a client establishes a connection, an ephemeral port number is chosen.
>> 2) when a server listening on a socket accepts a connection, a port
>> number is assigned.
>>
>> So in my understanding at any given time only maximum 65536 TCP/IP
>> connections can exist on a given machine.
>
>A TCP connection is identified by the source address, source port,
>destination address and destination port.  Lots more than 65536
>possibilities.
>
>--
>http://www.greenend.org.uk/rjk/

True, but it doesn't answer the OP's question.

[toc] | [prev] | [next] | [standalone]

#3427

Bob Martin <bob.martin@excite.com> wrote:
>in 503286 20150727 231134 Richard Kettlewell <rjk@greenend.org.uk> wrote:
>>g918273l@gmail.com writes:
>>> I have a specific question on implementing a load balancer or a TCP/IP
>>> server program that does TCP/IP.
>>>
>>> Since port number is 16 bits, there are a max of only 65536 ports on a
>>> single Linux box at any given time.
>>> And TCP/IP needs a port number to talk to the outside world.
>>> 1) when a client establishes a connection, an ephemeral port number is chosen.
>>> 2) when a server listening on a socket accepts a connection, a port
>>> number is assigned.
>>>
>>> So in my understanding at any given time only maximum 65536 TCP/IP
>>> connections can exist on a given machine.
>>
>>A TCP connection is identified by the source address, source port,
>>destination address and destination port.  Lots more than 65536
>>possibilities.
>>
>>--
>>http://www.greenend.org.uk/rjk/
>
>True, but it doesn't answer the OP's question.

Certainly it does...  The port number only specifies the
specific server program that will respond to requests on
a given machine.  There might be many thousands of
connections to that one program, on that one port.

Consider for example that port 80 is normally assigned
to the HTTP server, and there are commonly hundreds or
thousands of browsers connected to many of the busier
web servers.

In addition to just that one port, the same machine
might also have server programs listening to dozens of
other ports at the same time.  There might be thousands
of TCP/IP connections to each of several different ports.
FTP, HTTP, HTTPS, SMTP, SSH, NTTP, POP3, and many
others.

The 16 bit size of the port number only limits the
number of services, handled by that many different
server programs.

-- 
Floyd L. Davidson                         http://www.apaflo.com/
Ukpeagvik (Barrow, Alaska)                      floyd@apaflo.com

[toc] | [prev] | [next] | [standalone]

#3428

floyd@apaflo.com (Floyd L. Davidson) writes:
> Bob Martin <bob.martin@excite.com> wrote:
>>in 503286 20150727 231134 Richard Kettlewell <rjk@greenend.org.uk> wrote:
>>>g918273l@gmail.com writes:
>>>> I have a specific question on implementing a load balancer or a TCP/IP
>>>> server program that does TCP/IP.
>>>>
>>>> Since port number is 16 bits, there are a max of only 65536 ports on a
>>>> single Linux box at any given time.
>>>> And TCP/IP needs a port number to talk to the outside world.
>>>> 1) when a client establishes a connection, an ephemeral port
>>>> number is chosen.
>>>> 2) when a server listening on a socket accepts a connection, a port
>>>> number is assigned.
>>>>
>>>> So in my understanding at any given time only maximum 65536 TCP/IP
>>>> connections can exist on a given machine.
>>>
>>>A TCP connection is identified by the source address, source port,
>>>destination address and destination port.  Lots more than 65536
>>>possibilities.
>>True, but it doesn't answer the OP's question.
>
> Certainly it does...  The port number only specifies the
> specific server program that will respond to requests on
> a given machine.  There might be many thousands of
> connections to that one program, on that one port.
>
> Consider for example that port 80 is normally assigned
> to the HTTP server, and there are commonly hundreds or
> thousands of browsers connected to many of the busier
> web servers.
>
> In addition to just that one port, the same machine
> might also have server programs listening to dozens of
> other ports at the same time.  There might be thousands
> of TCP/IP connections to each of several different ports.
> FTP, HTTP, HTTPS, SMTP, SSH, NTTP, POP3, and many
> others.
>
> The 16 bit size of the port number only limits the
> number of services, handled by that many different
> server programs.

It doesn’t even limit that.  Maximum number of listeners = numbers of
possible ports multiplied by number of local addresses.  Now it’s
certainly true that a common configuration is only one local address (or
two if you have IPv6) (other than loopback) and for listeners to bind to
all local addresses, but it’s not the only possibility.

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#3429

On Mon, 2015-07-27, g918273l@gmail.com wrote:
> Hi All,
>
> I have a specific question on implementing a load balancer or a TCP/IP
> server program that does TCP/IP.
>
> Since port number is 16 bits, there are a max of only 65536 ports on a
> single Linux box at any given time.
> And TCP/IP needs a port number to talk to the outside world.

Nitpick: it helps if you write "TCP" when you mean TCP.  "TCP/IP" was
a term you saw a lot in the 1990s, but I never understood what it
meant ... possibly it was simply used when "IP" didn't look impressive
enough.

/Jorgen

-- 
  // Jorgen Grahn <grahn@  Oo  o.   .     .
\X/     snipabacken.se>   O  o   .

[toc] | [prev] | [next] | [standalone]

#3430

On 28/07/2015 11:15, Jorgen Grahn wrote :
> On Mon, 2015-07-27, g918273l@gmail.com wrote:
>> Hi All,
>>
>> I have a specific question on implementing a load balancer or a TCP/IP
>> server program that does TCP/IP.
>>
>> Since port number is 16 bits, there are a max of only 65536 ports on a
>> single Linux box at any given time.
>> And TCP/IP needs a port number to talk to the outside world.
> 
> Nitpick: it helps if you write "TCP" when you mean TCP.  "TCP/IP" was
> a term you saw a lot in the 1990s, but I never understood what it
> meant ... possibly it was simply used when "IP" didn't look impressive
> enough.
> 
> /Jorgen
> 

TCP/IP means TCP over IP ... (TCP = layer 4 of OSI model, IP  is at
layer 3)... OK now, I have not seen TCP over anything else than IP ...
OSI, IPX, or DECnet stacks do not implement TCP at layer 4 to my
knowledge... right?

[toc] | [prev] | [next] | [standalone]

#3431

On Tuesday July 28 2015 12:29, in comp.os.linux.networking, "Denis Corbin"
<news@dm3c.org> wrote:

> On 28/07/2015 11:15, Jorgen Grahn wrote :
>> On Mon, 2015-07-27, g918273l@gmail.com wrote:
>>> Hi All,
>>>
>>> I have a specific question on implementing a load balancer or a TCP/IP
>>> server program that does TCP/IP.
>>>
>>> Since port number is 16 bits, there are a max of only 65536 ports on a
>>> single Linux box at any given time.
>>> And TCP/IP needs a port number to talk to the outside world.
>> 
>> Nitpick: it helps if you write "TCP" when you mean TCP.  "TCP/IP" was
>> a term you saw a lot in the 1990s, but I never understood what it
>> meant ... possibly it was simply used when "IP" didn't look impressive
>> enough.
>> 
>> /Jorgen
>> 
> 
> TCP/IP means TCP over IP ... (TCP = layer 4 of OSI model, IP  is at
> layer 3)... OK now, I have not seen TCP over anything else than IP ...

Then, you haven't looked at VPN technologies.

It is possible (and common) for a VPN to interpose additional protocols
between TCP and the (normal) carrier protocol. So, you /can/ find TCP over
UDP over IP (for instance).

> OSI, IPX, or DECnet stacks do not implement TCP at layer 4 to my
> knowledge... right?


-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#3432

Le 28/07/2015 18:51, Lew Pitcher a écrit :
> On Tuesday July 28 2015 12:29, in comp.os.linux.networking, "Denis Corbin"
> <news@dm3c.org> wrote:
> 
>> On 28/07/2015 11:15, Jorgen Grahn wrote :
>>> On Mon, 2015-07-27, g918273l@gmail.com wrote:
>>>> Hi All,
>>>>
>>>> I have a specific question on implementing a load balancer or a TCP/IP
>>>> server program that does TCP/IP.
>>>>
>>>> Since port number is 16 bits, there are a max of only 65536 ports on a
>>>> single Linux box at any given time.
>>>> And TCP/IP needs a port number to talk to the outside world.
>>>
>>> Nitpick: it helps if you write "TCP" when you mean TCP.  "TCP/IP" was
>>> a term you saw a lot in the 1990s, but I never understood what it
>>> meant ... possibly it was simply used when "IP" didn't look impressive
>>> enough.
>>>
>>> /Jorgen
>>>
>>
>> TCP/IP means TCP over IP ... (TCP = layer 4 of OSI model, IP  is at
>> layer 3)... OK now, I have not seen TCP over anything else than IP ...
> 
> Then, you haven't looked at VPN technologies.

yes, but these are still part of the IP stack... so it's still "TCP over
IP".

> 
> It is possible (and common) for a VPN to interpose additional protocols
> between TCP and the (normal) carrier protocol. So, you /can/ find TCP over
> UDP over IP (for instance).

... yes TCP ... over IP. :)

> 
>> OSI, IPX, or DECnet stacks do not implement TCP at layer 4 to my
>> knowledge... right?
> 
> 

[toc] | [prev] | [next] | [standalone]

#3433

On Tuesday July 28 2015 17:27, in comp.os.linux.networking, "Denis Corbin"
<news@dm3c.org> wrote:

> Le 28/07/2015 18:51, Lew Pitcher a écrit :
>> On Tuesday July 28 2015 12:29, in comp.os.linux.networking, "Denis Corbin"
>> <news@dm3c.org> wrote:
>> 
>>> On 28/07/2015 11:15, Jorgen Grahn wrote :
>>>> On Mon, 2015-07-27, g918273l@gmail.com wrote:
>>>>> Hi All,
>>>>>
>>>>> I have a specific question on implementing a load balancer or a TCP/IP
>>>>> server program that does TCP/IP.
>>>>>
>>>>> Since port number is 16 bits, there are a max of only 65536 ports on a
>>>>> single Linux box at any given time.
>>>>> And TCP/IP needs a port number to talk to the outside world.
>>>>
>>>> Nitpick: it helps if you write "TCP" when you mean TCP.  "TCP/IP" was
>>>> a term you saw a lot in the 1990s, but I never understood what it
>>>> meant ... possibly it was simply used when "IP" didn't look impressive
>>>> enough.
>>>>
>>>> /Jorgen
>>>>
>>>
>>> TCP/IP means TCP over IP ... (TCP = layer 4 of OSI model, IP  is at
>>> layer 3)... OK now, I have not seen TCP over anything else than IP ...
>> 
>> Then, you haven't looked at VPN technologies.
> 
> yes, but these are still part of the IP stack... so it's still "TCP over
> IP".


OK then, how about RFC 1791: TCP and UDP over IPX
(https://tools.ietf.org/html/rfc1791) ?

TCP is TCP; it corresponds (loosly) to an OSI level 4 protocol (loosly,
because the internetworking protocols were not developed to the OSI model).

It matters not to TCP whether it is carried by IP, IPX, DECNET (or any other
OSI level 3 "network layer" protocol), or encapsulated in UDP packets (or any
other OSI level 4 protocol), or even by Avian carrier.

So, TCP can refer to *any number* of TCP/network_layer combinations, *one* of
which is TCP/IP.


[snip]

-- 
Lew Pitcher
"In Skills, We Trust"
PGP public key available upon request

[toc] | [prev] | [next] | [standalone]

#3435

>>>>
>>>> TCP/IP means TCP over IP ... (TCP = layer 4 of OSI model, IP  is at
>>>> layer 3)... OK now, I have not seen TCP over anything else than IP ...
>>>
>>> Then, you haven't looked at VPN technologies.
>>
>> yes, but these are still part of the IP stack... so it's still "TCP over
>> IP".
> 
> 
> OK then, how about RFC 1791: TCP and UDP over IPX
> (https://tools.ietf.org/html/rfc1791) ?

Interesting!

A funny thing in this RFC is the use of "TCP/IP" as discussed previously
in this thread. For example in the introduction you can read:

	"to let TCP/IP applications run over IPX, we would need to have TCP and
UDP run over IPX"

Obviously here "TCP/IP applications" stands for "TCP and/or UDP based
applications"... which makes this sentence a Lapalissade... else such
applications would need IP protocol and could not be used over IPX by
simply putting TCP over IPX nor UDP over IPXF over IPX as described in
this RFC.

I was not aware it was common in the last century to use "TCP/IP" for
designing either TCP or probably rather the IP stack as a whole.

Thanks for this reference.

> 
> 
> [snip]
> 

[toc] | [prev] | [next] | [standalone]

#3442

Hi Gargi,

g918273l@gmail.com wrote:

> I have a specific question on implementing a load balancer or a TCP/IP
> server program that does TCP/IP.
> 
> Since port number is 16 bits, there are a max of only 65536 ports on a
> single Linux box at any given time.  And TCP/IP needs a port number to
> talk to the outside world.  
> 1) when a client establishes a connection, an ephemeral port number
>    is chosen.  
> 2) when a server listening on a socket accepts a connection, a port 
>    number is assigned.
> 
> So in my understanding at any given time only maximum 65536 TCP/IP
> connections can exist on a given machine.

No. As pointed out elsewhere, only 65536 different services may be
differentiated. A TCP connection is identified by source-IP, source-port
(choosen "randomly" by client, different for multiple connections to
same server port), server-IP, desintation-port.

> So how is it that some or most load balancers claim 200,000 or more
> concurrent connections?
> 
> Can someone please explain that?

A service, e.g. running on port 80, is able to receive many, many
connections on the same port.

> Also regarding load balancers, once a load balancer has forwarded a
> request to one of the servers behind it, can the load balancer somehow
> pass some information to it, that will help the server to respond back
> to the originating client directly to avoid the latency of sending
> back the response via the load balancer?

I'm not aware of a way to achieve this on network level, because even if
you use DNAT, the packets still need to go back via load balancer since
it needs to re-write the sender address of the server's response.

There might be application level solutions (like redirecting from
www.yourdomein.com to www1...www4.yourdomain.com). On network level you
somehow need to keep the client's "illusion" that it's talking to one
server.

I'm no load balancing expert though and happy to learn something new.
:-)

Jamma.

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."

www.tisc.de

[toc] | [prev] | [next] | [standalone]

#3443

On 06/08/15 12:12, Jamma Tino Schwarze wrote:
<snip>

>
> No. As pointed out elsewhere, only 65536 different services may be
> differentiated. A TCP connection is identified by source-IP, source-port
> (choosen "randomly" by client, different for multiple connections to
> same server port), server-IP, desintation-port.
>

Nothing to do with load balancing, but I'm puzzled about the numbers 
flying around.

65536? Minus 1023 that is. 0 won't be a valid portnumber. And ports 
1-1024 won't be advised (I hope); these are reserved for root-usage.

So that leaves 64512. Or thereabout.

But that number should (or am I wrong) be multiplied by the number of 
network interfaces your machine has. Eacht network interface has it's 
own IP number, or?

Just my 2p. And forgive me if I'm off-topic.


-- 
Greets, JT

[toc] | [prev] | [next] | [standalone]

#3448

On 2015-08-06, JT <JT-reply-only@newsgroup.nl> wrote:

> On 06/08/15 12:12, Jamma Tino Schwarze wrote:
> <snip>
>
>> No. As pointed out elsewhere, only 65536 different services may be
>> differentiated. A TCP connection is identified by source-IP, source-port
>> (choosen "randomly" by client, different for multiple connections to
>> same server port), server-IP, desintation-port.
>
> Nothing to do with load balancing, but I'm puzzled about the numbers 
> flying around.
>
> 65536? Minus 1023 that is. 0 won't be a valid portnumber. And ports 
> 1-1024 won't be advised (I hope); these are reserved for root-usage.
>
> So that leaves 64512. Or thereabout.
>
> But that number should (or am I wrong) be multiplied by the number of 
> network interfaces your machine has. Eacht network interface has it's 
> own IP number, or?
>
> Just my 2p. And forgive me if I'm off-topic.

Let me take a crack at it.  A program running on a given machine and
listening on a particular port number can accept any number of connections
on that port number - even if they all come from the same machine.
For example, imagine your server is at 10.0.0.1 and is listening on
port 1234.  A machine at 10.0.0.2 can open a connection to your server;
it'll probably be assigned a random port number (e.g. 24576).  The four
items that uniquely identify the connection are as follows:

Server IP address  Server port  Client IP address  Client port
-----------------  -----------  -----------------  -----------
    10.0.0.1          1234          10.0.0.2          24576

If another client, at IP address 10.0.0.3, connects, the list of
connections might look like this:

    10.0.0.1          1234          10.0.0.2          24576
    10.0.0.1          1234          10.0.0.3          31400

Now suppose the first client opens another connection to the
server.  It'll grab another random port number, and the list
might now look like this:

    10.0.0.1          1234          10.0.0.2          24576
    10.0.0.1          1234          10.0.0.3          31400
    10.0.0.1          1234          10.0.0.2          25212

Because each line of the list differs in some form, everything
is OK.  Note that you could even run this experiment entirely
on one machine; in the list above all IP addresses would be
replaced with 10.0.0.1.  Note also that this works even if
each machine has only one network interface.

Been there, done that, wrote the source code.

-- 
/~\  cgibbs@kltpzyxm.invalid (Charlie Gibbs)
\ /  I'm really at ac.dekanfrus if you read it the right way.
 X   Top-posted messages will probably be ignored.  See RFC1855.
/ \  HTML will DEFINITELY be ignored.  Join the ASCII ribbon campaign!

[toc] | [prev] | [next] | [standalone]

#3449

JT <JT-reply-only@newsgroup.nl> wrote:
> But that number should (or am I wrong) be multiplied by the number
> of network interfaces your machine has. Eacht network interface has
> it's own IP number, or?

You don't necessarily need to have multiple network interfaces - one
can have multiple IPs per network interface.  And depending on whether
one's system/stack adheres to the strong versus weak end system model
the IP addresses are either a property of the interface or of the
system as a whole.

rick
-- 
The glass is neither half-empty nor half-full. The glass has a leak.
The real question is "Can it be patched?"
these opinions are mine, all mine; HP might not want them anyway... :)
feel free to post, OR email to rick.jones2 in hp.com but NOT BOTH...

[toc] | [prev] | [next] | [standalone]

#3487

JT <JT-reply-only@newsgroup.nl> wrote:

>> No. As pointed out elsewhere, only 65536 different services may be
>> differentiated. A TCP connection is identified by source-IP, source-port
>> (choosen "randomly" by client, different for multiple connections to
>> same server port), server-IP, desintation-port.
> 
> Nothing to do with load balancing, but I'm puzzled about the numbers 
> flying around.
> 
> 65536? Minus 1023 that is. 0 won't be a valid portnumber. And ports 
> 1-1024 won't be advised (I hope); these are reserved for root-usage.

On TCP/UDP-level nobody cares about that Unix tradition of reserving 1-1024
to root processes. These are valid port numbers and may be used.

One IP = up to 65535 different TCP ports. Period. Another 65535 for UDP
and maybe different IP protocols which use some kind of port number.

> And forgive me if I'm off-topic.

Slightly. ;-) The original question whas about number of simulateneous
tcp/ip connections. Which is a completely different issue.

Another perspective: Given one IP (=server) running exactly one service,
one particular client cannot open more than 65535 connections to that
service - in theory! In practice, probably a lot less because not all
source port numbers will be available for use. It's not a problem on
server side, but client side this time.

If that one server runs a second service on a different port, the same
client might be able to establish another 65535 connections. In theory!
I'm not sure whether common operating systems will allocate the same
source port for different destinations. Maybe, maybe not. 

But that's all theory and my (non-TCP/IP expert) half-knowledge. ;-)

Jamma.

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."

www.tisc.de

[toc] | [prev] | [next] | [standalone]

#3492

Jamma Tino Schwarze <jamma-usenet@tisc.de> writes:
> Another perspective: Given one IP (=server) running exactly one service,
> one particular client cannot open more than 65535 connections to that
> service - in theory! In practice, probably a lot less because not all
> source port numbers will be available for use. It's not a problem on
> server side, but client side this time.

The client could use more than one IP address (although client software
is not usually smart enough to exploit this).

-- 
http://www.greenend.org.uk/rjk/

[toc] | [prev] | [next] | [standalone]

#3495

Richard Kettlewell <rjk@greenend.org.uk> wrote:

>> Another perspective: Given one IP (=server) running exactly one service,
>> one particular client cannot open more than 65535 connections to that
>> service - in theory! In practice, probably a lot less because not all
>> source port numbers will be available for use. It's not a problem on
>> server side, but client side this time.
> 
> The client could use more than one IP address (although client software
> is not usually smart enough to exploit this).

You are granted today's nitpicking award! :-)

Of course, you are right - if there were multiple suitable IP addressses
available to the client.

Jamma.

-- 
"What we nourish flourishes." - "Was wir nähren erblüht."

www.tisc.de

[toc] | [prev] | [next] | [standalone]

#3625

Hello All, 

Check this andriod app. Its really awesome. 

This app have all the dumps for Linux. Its really Awesome. 

https://play.google.com/store/apps/details?id=com.fromdrive.dumpsdrive&hl=en 

[toc] | [prev] | [standalone]

Back to top | Article view | comp.os.linux.networking

csiph-web