Updating client's port information
Zilla
- several clients can connect to a listening port, say 5001, on a
server daemon
- server daemon forks after accepting the connection, and uses a new
port, say 5002; daemon can spawn up to four children; each child can
handle multiple clients.
What is the "standard" (if it exists) way to update the client's port
info so it communictes on port 5002 instead of port 5001?
So now if I want another client to talk to the newly spawned server
child, I tell it to use port 5002.
GArlington
Probably the more common way is NOT to change the port at all...
Your server listens on predefined port, accepts client connection,
passes client socket to processing thread [child], from there on the
processing thread is communicating with the client and main server
carries on listening/waiting for new connections...
Zilla
Ok, fair enough, that's what I did originally, and works as you
explained it. But I want to do BOTH of the following
1. Connect a new client so the "same" server child the first client is
connected to.
2. Connect a new client to yet another server child.
#2 is taken care of by your explanation. But how about #1? IIRC, I'll
need a host/port pair for a client to connect to a server.
Zilla
>
> - Show quoted text -
...or even yet...
3. Currently I have two connections established, say, client1/server1
and client2/server2. Now I want client2a to connect to server2, NOT
server1. How? I guess this is just a variation of my #2.
Zilla
>
> - Show quoted text -
I'm sorry, it's a variation of my #1 case.
David Schwartz
> ...or even yet...
> 3. Currently I have two connections established, say, client1/server1
> and client2/server2. Now I want client2a to connect to server2, NOT
> server1. How? I guess this is just a variation of my #2.
Okay, let's follow it through:
1) Client connects to server1 in port 5000.
2) Server1 forks, client is now connected to server2.
3) New clients can still connect to server1 on port 5000.
4) Server 2 can now open an additional port, say 5001 if it wants.
This will have no effect on its existing connections.
5) Clients can now connect to server1 on port 5000 and server2 on port
5001.
DS
GArlington
Sorry, I can not understand what you are trying to do...
In my understanding [and in general concepts] clients are NEVER
related, i.e. client2a [as you describe it] NEVER knows if it is 2a OR
1c OR 15g [if it try to follow your definitions]...
How does your client2a KNOWS that it is client2a and NOT client3b? In
other words how is it supposed to know which server to connect to?
By the look of it you are trying to achieve something like servers
load balancing on the client side...
If this IS what you are trying to achieve than it is done on the
server, NOT on the client...
Or, maybe I misunderstand you completely...
GArlington
BTW: to "advertise" available ports it is common to use UDP [broadcast/
multicast]...
Zilla
Yes this is what I want to do. With your step 5), I know how the first
part works, where clients can still connect to server1 on port 5000. I
am indeed trying to achieve the second part, where a 2nd client will
connect to server2 on port 5001, but how does can it know that the
port # "is" 5001? IOW, how can server2, not server1, now tell new
clients its port number?
Zilla
>
> - Show quoted text -
The names I gave the clients are arbitrary, call them Joe, Mary, and
Martha if you want. The important concept I'm trying to achieve is if
Joe is connected to child server2, how can Mary connect to the same
child server2, while Martha is connected to server1.
Zilla
>
> - Show quoted text -
Ok, I'll look into multicasting since I don't necessarily want to
broadcast.
Jim Logajan
I'm confused - what is stopping the forked server process from sending the
newly opened listening port number back to the client over the original
client connection? If the data flowing over these connections are an
application-specific protocol you have designed, then you can design the
protocol to do just that.
For that matter, it isn't clear to me what problem you are trying to solve
that requires a second connection that you can't accomplish with an
appropriately designed protocol running over a single connection.
Zilla
>
> - Show quoted text -
I'm not trying to "solve a problem". I'm trying to learn how to do
what you just suggested. You suggest "design the protocol to do just
that.", I'm saying "how?"
Zilla
>
> - Show quoted text -
Maybe you folks are right - I may be trying to make this more
difficult than it really is - perhaps from my lack of understanding.
The fundamental problem I'm trying to solve is - how can a second
client connect to an "existing child server" without forking a new
server, vs. a second client connecting to the parent server and indeed
forking a second child server.
Zilla
>
> - Show quoted text -
BTW, I want to be able to do BOTH - that is - a second client connect
to an existing child server, AND/OR, a second client connecting to the
parent server.
Barry Margolin
<e0bcc130-4812-4245...@8g2000hse.googlegroups.com>,
Zilla <zil...@bellsouth.net> wrote:
> I'm not trying to "solve a problem". I'm trying to learn how to do
> what you just suggested. You suggest "design the protocol to do just
> that.", I'm saying "how?"
What he meant was "Why does a client need to connect to the child
server?" What is your overall application that requires this connection
strategy?
How is the client that needs to connect to the child server related to
the original client for whom the child was forked in the first place?
In another post you asked how the new client finds out the new port that
the child server is listening on. If the new client is able to
communicate with the original client, the server could tell the original
client the port, and the original client can pass this on to the new
client.
The general issue is that when you start serving a port that isn't well
known, you need an out-of-band way to tell this port number to the
clients. There are services like portmapper, but they just push the
problem back a level -- instead of having a well-known port number, you
have a well-known program number, which the port mapper translates to a
port.
--
Barry Margolin, bar...@alum.mit.edu
Arlington, MA
*** PLEASE don't copy me on replies, I'll read them in the group ***
GArlington
That is exactly what I am trying to understand...
Is there some kind of relationship/grouping between clients?
If you intend to have limited number of predefined groups, then just
start this limited number of servers on predefined ports...
If not, then the question still is: how does client3 [sequential
connection number] guess which server it needs to connect to? In your
above scenario WHY will "Mary" want to connect to "server2" and NOT to
"server1" and HOW do you expect "Mary" to KNOW which server to connect
to?
Zilla
>
> - Show quoted text -
I have my design reasons, but did not want to delve into them here.
However since you asked...
I want to connect to a remote host that can spawn up to four
independent servers, each server being an functional clone, but runs
as a separate process. I have a daemon that listens to connectons, and
if gets one, spawns one of these servers. Ok?
Now on a local host I can have a client application that can connect
to the daemon to spawn one child server. This client sends commands
and gets responses from its server.
Since the remote host can spawn up to 4 servers, I can have at least 4
different clients, from different local hosts if need be, connected to
the 4 different servers, yes?
This is straight-forward client/server tcp/ip so far correct?
Say Mary has a connection to child server1, and Martha to child
server2. Now Mary sees and issue with some of the data she's
collecting and calls John on the phone for help. So now John needs to
start a functionally similar client as Mary, and needs to connect to
server1 so he can repeat the tests Mary is doing and see the erroneous
data.
Martha can call John as well to ask him for help, and in this case
John spawns yet another similarly functional client as Martha's, and
this time he needs to talk to server2.
Long and winded, but that's the gist of my application.
David Schwartz
> Martha can call John as well to ask him for help, and in this case
> John spawns yet another similarly functional client as Martha's, and
> this time he needs to talk to server2.
>
> Long and winded, but that's the gist of my application.
So when Martha calls John, she has to tell him, "I'm on server X". So
the simplest way to do this is for each server to open up an
additional port when it starts and tell the client that this is it's
server number.
DS
Zilla
You meant "...tell the client that this is it's PORT (not server)
number" correct? This is a catch 22 isn't it? Martha's server has to
tell John's client to connect to port Y, but doesn't John's client
have to know the value of Y before able to connect to Martha's server?
This is precisely why I started the thread.
David Schwartz
> > So when Martha calls John, she has to tell him, "I'm on server X". So
> > the simplest way to do this is for each server to open up an
> > additional port when it starts and tell the client that this is it's
> > server number.
> You meant "...tell the client that this is it's PORT (not server)
> number" correct?
There is no difference. The server number simply has to be unique, so
the server can open a port and call whatever port number it gets its
server number. Martha doesn't care what the number is.
> This is a catch 22 isn't it?
No.
> Martha's server has to
> tell John's client to connect to port Y,
No, *Martha* tells John to connect to port Y. Martha knows what server
number she connected to because she's connected to it.
> but doesn't John's client
> have to know the value of Y before able to connect to Martha's server?
Yes. That's why Martha says to John, "I'm having a problem, and I'm on
server N."
> This is precisely why I started the thread.
You said if Martha had a problem, she would ask John to connect to her
server. She knows what server she connected to, because she's
connected to it. Otherwise, how would John know he had to do anything
at all?
In order for John to know that Martha needs him to do anything, Martha
has to say something to John. Martha knows what server she's connected
to, because the server can tell her. So she can pass that information
to John.
Alternatively, you can have a central agent that keeps track of which
servers are handling which clients and ports they have open. Then John
can connect to the central agent (on a fixed port) and ask it what
server Martha is using. If desired, the central agent could even 'hand
off' the connection to Martha's server using IPC.
DS
Zilla
First off, thanks everyone's help and patience.
Ok I'm unclear about the "additional port" you mentioned. Here's a
typical tcp/ip session correct?
- Daemon listens on IP-X/port-X
- Martha's client on IP-Y/port-Yconnects to daemon
- Daemon connects to Martha's client, and forks child server1, which
still using
port X, if I understand tcp/ip correctly. IOW, the server1 now has
a "coonected" socket instead of a "listening" socket, but still
"same" port-X?
- Now the IP/port pair exists for Martha's tcp/ip connection to
server1, namely,
IP-X/port-X connected to IP-Y/port-Y, correct?
- Also, server1 opens up "additional port-Z"??? Is this your
suggestion?.
If I got that correctly, how will John's client now know to connect to
IP-X/port-Z, and not IP-X/port-Y, because if John's client connects to
the original, IP-X/port-X, that's the listening port now, which will
spawn a second server2 for John, which is NOT what I want. Correct?
David Schwartz
> First off, thanks everyone's help and patience.
> Ok I'm unclear about the "additional port" you mentioned. Here's a
> typical tcp/ip session correct?
> - Daemon listens on IP-X/port-X
> - Martha's client on IP-Y/port-Yconnects to daemon
> - Daemon connects to Martha's client, and forks child server1, which
> still using
> port X, if I understand tcp/ip correctly. IOW, the server1 now has
> a "coonected" socket instead of a "listening" socket, but still
> "same" port-X?
It really doesn't make sense to say that "same" port. One is a
listening port, the other is the connected local port. While they have
the same number, a listening socket only has a single port and a
connected socket has two, so it's not very sensible to compare them.
> - Now the IP/port pair exists for Martha's tcp/ip connection to
> server1, namely,
> IP-X/port-X connected to IP-Y/port-Y, correct?
> - Also, server1 opens up "additional port-Z"??? Is this your
> suggestion?.
Yes. That way, the new server has a listening port as well.
> If I got that correctly, how will John's client now know to connect to
> IP-X/port-Z, and not IP-X/port-Y, because if John's client connects to
> the original, IP-X/port-X, that's the listening port now, which will
> spawn a second server2 for John, which is NOT what I want. Correct?
How does John know to connect at all? How does John know IP-X?
Somehow, Martha has to tell John "I have a problem, can you connect to
my server?" So why can't she say, "I have a problem, can you connect
to server 5103?".
If that's not good enough, then make a central registration server.
When Martha's server opens up an additional port, it can register with
a central server, "I'm server 5103, and I'm serving Martha". Then John
can connect to the central server (on a well-known IP and port) and
find out what port to connect to.
DS
Zilla
> On Sep 5, 12:02 pm, Zilla <zill...@bellsouth.net> wrote:
>
> > First off, thanks everyone's help and patience.
> > Ok I'm unclear about the "additional port" you mentioned. Here's a
> > typical tcp/ip session correct?
> > - Daemon listens on IP-X/port-X
> > - Martha's client on IP-Y/port-Yconnects to daemon
> > - Daemon connects to Martha's client, and forks child server1, which
> > still using
> > port X, if I understand tcp/ip correctly. IOW, the server1 now has
> > a "coonected" socket instead of a "listening" socket, but still
> > "same" port-X?
>
> It really doesn't make sense to say that "same" port. One is a
> listening port, the other is the connected local port. While they have
> the same number, a listening socket only has a single port and a
> connected socket has two, so it's not very sensible to compare them.
>
Yes, that makes sense!
> > - Now the IP/port pair exists for Martha's tcp/ip connection to
> > server1, namely,
> > IP-X/port-X connected to IP-Y/port-Y, correct?
> > - Also, server1 opens up "additional port-Z"??? Is this your
> > suggestion?.
>
> Yes. That way, the new server has a listening port as well.
>
> > If I got that correctly, how will John's client now know to connect to
> > IP-X/port-Z, and not IP-X/port-Y, because if John's client connects to
> > the original, IP-X/port-X, that's the listening port now, which will
> > spawn a second server2 for John, which is NOT what I want. Correct?
>
> How does John know to connect at all? How does John know IP-X?
> Somehow, Martha has to tell John "I have a problem, can you connect to
> my server?" So why can't she say, "I have a problem, can you connect
> to server 5103?".
This is where my lack of understanding shows! John knows IP-X/port-X,
but not IP-X/port-Z correct? In your example, what is the "listening
port number"? Is it 5103, or something else?
>
> If that's not good enough, then make a central registration server.
> When Martha's server opens up an additional port, it can register with
> a central server, "I'm server 5103, and I'm serving Martha". Then John
> can connect to the central server (on a well-known IP and port) and
> find out what port to connect to.
>
> DS
Yes I actually like this idea.