Multiple connections to the same service

Hello,

I hope this question is not too boring for you.

A friend and I are just discussing how multiple connections
to the same service at the same time can be accomplished:

Do both connections use the same socket at the server side?
How does the service then distinguish between the two clients?

Or is it so, that usually a master service is listening for
example at port 80 - and after a client has established a
connection, the service is continued at another port of the
server machine (let us say 7777), which was previously unused.
And the master service continues listening at port 80
to serve the next client.

Thank you.

Michael Mueller

On 2005-02-08, Michael Mueller <(E-Mail Removed)> wrote:
> Or is it so, that usually a master service is listening for
> example at port 80 - and after a client has established a

This is what is usually done.
Davide

--
You all have to admit that Microsoft products provide a quality unmatched
by any other company. That is why I am switching to 100% pure shredded
Microsoft certificates of authenticity in my hamster's cage.
-- From a Slashdot.org post

Michael Mueller <(E-Mail Removed)> said:
>I hope this question is not too boring for you.
>
>A friend and I are just discussing how multiple connections
>to the same service at the same time can be accomplished:
>
>Do both connections use the same socket at the server side?
>How does the service then distinguish between the two clients?

A 'connection' is determined by four pieces of data:
source and destination IP addresses, and port numbers at source and
destination systems. I hope this answers your question.

>Or is it so, that usually a master service is listening for
>example at port 80 - and after a client has established a
>connection, the service is continued at another port of the
>server machine (let us say 7777), which was previously unused.

No, only few programs create a new connection after first discussing
with some "service broker/mapper" service at a known port. And firewall
admins tend to curse whenever one of these "connect first to a known
port, then connect to a 'random' one" -protocols are required to pass
through a firewall.


So, for example with Apache web server (v1.3, and v2.0 in forked mode),
there is one master process listening on the service port (typically 80).
When a connection from a remote machine comes, the master process
establishes the connection, and then looks for a unoccupied child process
to handle the actual request; the connection handle is then passed to the
child process, which reads the actual request and writes back the response.
The port on the server side doesn't change during the request processing
(and neither does the port on the client side).
--
Wolf a.k.a. Juha Laiho Espoo, Finland
(GC 3.0) GIT d- s+: a C++ ULSH++++$ P++@ L+++ E- W+$@ N++ !K w !O !M V
PS(+) PE Y+ PGP(+) t- 5 !X R !tv b+ !DI D G e+ h---- r+++ y++++
"...cancel my subscription to the resurrection!" (Jim Morrison)

Davide Bianchi wrote:

>>Or is it so, that usually a master service is listening for
>>example at port 80 - and after a client has established a
>
>
> This is what is usually done.

Thank you very much for your fast response.

Can you give me a link where I can read more about that
or a search phrase that makes sense when using google.
I seem not to be able to figure out by myself.

Michael Mueller

"Michael Mueller" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...

> A friend and I are just discussing how multiple connections
> to the same service at the same time can be accomplished:
>
> Do both connections use the same socket at the server side?

No.

> How does the service then distinguish between the two clients?

Because the two connections do not use the same socket. The server would
then have three sockets, one on which it was listening for new connections,
and the two connections it already received on the first socket.

> Or is it so, that usually a master service is listening for
> example at port 80 - and after a client has established a
> connection, the service is continued at another port of the
> server machine (let us say 7777), which was previously unused.
> And the master service continues listening at port 80
> to serve the next client.

Umm, no. All the connections are *TO* the same port. The server tells
them apart because they are distinct sockets. When you accept a connection
on a listening socket, you get a new socket for that new connection.

The networking stack tells the packets apart because they are from
different IPs/ports. When the network stack tries to figure out what
connection a TCP packet is part of, it looks at four things: the source IP,
the source port, the destination IP, and the destination port. If the same
computer wants to make two connections from the same IP, to the same IP, and
both to port 80, it would use two different source ports. Most clients, when
they make a connnection to a server, don't care about the source port, and
the system assigns it an unused source port.

DS

"Davide Bianchi" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed) .net...
> On 2005-02-08, Michael Mueller <(E-Mail Removed)> wrote:
>> Or is it so, that usually a master service is listening for
>> example at port 80 - and after a client has established a
>
> This is what is usually done.

Actually, this is quite rare.

DS

Michael Mueller wrote:
> Hello,
>
.....
> Or is it so, that usually a master service is listening for
> example at port 80 - and after a client has established a
> connection, the service is continued at another port of the
> server machine (let us say 7777), which was previously unused.
> And the master service continues listening at port 80
> to serve the next client.
>
> Thank you.
>
> Michael Mueller

Please specify if you are talking about HTTP protocol. In HTTP a
connection lasts only as long as an html file is transmitted or whatever
you are generating. HTTP is not designed to stay connected. That's why
banks have so many security problems with online banking when they don't
use HTTPS.

In other protocols like FTP, you are connected from login until you type
'bye' or execute some disconnect command.

And, believe me, online applications that require 'connection',
'session', 'login' etc. would have been better off with FTP.

But on the application level, if you can trace your clients, you can use
other methods and call them 'connection'.

'bye'.

"Tosca Berisha" <(E-Mail Removed)> wrote in message
news:h8eOd.18892$(E-Mail Removed). ..

> Please specify if you are talking about HTTP protocol. In HTTP a
> connection lasts only as long as an html file is transmitted or whatever
> you are generating. HTTP is not designed to stay connected. That's why
> banks have so many security problems with online banking when they don't
> use HTTPS.

This isn't really true anymore. HTTP/1.1 and later specify a protocol
for persistent HTTP connections. An HTTP/1.1 protocol exchange assumes
persistent connections by default, and the client must specifically say if
it doesn't want one. Here was the first reasonable looking web page I found
about this
http://java.sun.com/j2se/1.5.0/docs/...keepalive.html just the
first section.

DS

David Schwartz wrote:
> "Michael Mueller" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
>
>
>>A friend and I are just discussing how multiple connections
>>to the same service at the same time can be accomplished:
>>
>>Do both connections use the same socket at the server side?
>
>
> No.

David,
can you give me a good link where I can read more
or can you give me a hint which search phrases I
should use for google?
I want to read more about that but I seeem not
to be able to find the right sources.

Thank you.

Michael Mueller

David Schwartz wrote:
> "Tosca Berisha" <(E-Mail Removed)> wrote in message
> news:h8eOd.18892$(E-Mail Removed). ..
>
>
>>Please specify if you are talking about HTTP protocol. In HTTP a
>>connection lasts only as long as an html file is transmitted or whatever
>>you are generating. HTTP is not designed to stay connected. That's why
>>banks have so many security problems with online banking when they don't
>>use HTTPS.
>
>
> This isn't really true anymore. HTTP/1.1 and later specify a protocol
> for persistent HTTP connections. An HTTP/1.1 protocol exchange assumes
> persistent connections by default, and the client must specifically say if
> it doesn't want one. Here was the first reasonable looking web page I found
> about this
> http://java.sun.com/j2se/1.5.0/docs/...keepalive.html just the
> first section.
>
> DS
>
>
Well that is not part of the design, that part of the "Oops, I guess we
need persistent connections, let stick in there somewhere".

That solution of HTTP 1.1 is not good enough. I has too many problems.
Actually using it is so terrible.

What I want to say is that we need a new protocol for persistent
connections, with persistent connections in mind, and maybe only with
persistent connections in mind.

Check out FTP. Once user is logged in a session is started and traced by
communication handle of the protocol, not with some cookies or from
variable or extra long encoded URL string all of these are so fragile
and unreliable, and so supported little. And on top of that incompatible
with popular browser.

TB