Updating client's port information - TCP-IP

This is a discussion on Updating client's port information - TCP-IP ; On Sep 4, 1:57*pm, Zilla wrote: > > 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 > ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 24 of 24

Thread: Updating client's port information

  1. Re: Updating client's port information

    On Sep 4, 1:57*pm, Zilla wrote:

    > > 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

  2. Re: Updating client's port information

    On Sep 4, 5:12*pm, David Schwartz wrote:
    > On Sep 4, 1:57*pm, Zilla wrote:
    >
    > > > 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


    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?






  3. Re: Updating client's port information

    On Sep 5, 12:02*pm, Zilla 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.

    > - 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

  4. Re: Updating client's port information

    On Sep 5, 3:16*pm, David Schwartz wrote:
    > On Sep 5, 12:02*pm, Zilla 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.


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2