Updating client's port information - TCP-IP

This is a discussion on Updating client's port information - TCP-IP ; I'm trying to write a client/server app where I can do the following: - 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 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 24

Thread: Updating client's port information

  1. Updating client's port information

    I'm trying to write a client/server app where I can do the following:
    - 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.

  2. Re: Updating client's port information

    On Aug 28, 4:39*pm, Zilla wrote:
    > I'm trying to write a client/server app where I can do the following:
    > - 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.


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

  3. Re: Updating client's port information

    On Aug 28, 12:03*pm, GArlington wrote:
    > On Aug 28, 4:39*pm, Zilla wrote:
    >
    > > I'm trying to write a client/server app where I can do the following:
    > > - 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.

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


    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.


  4. Re: Updating client's port information

    On Aug 28, 12:26*pm, Zilla wrote:
    > On Aug 28, 12:03*pm, GArlington wrote:
    >
    >
    >
    >
    >
    > > On Aug 28, 4:39*pm, Zilla wrote:

    >
    > > > I'm trying to write a client/server app where I can do the following:
    > > > - 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.

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

    >
    > 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.- Hide quoted text -
    >
    > - 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.

  5. Re: Updating client's port information

    On Aug 28, 12:51*pm, Zilla wrote:
    > On Aug 28, 12:26*pm, Zilla wrote:
    >
    >
    >
    >
    >
    > > On Aug 28, 12:03*pm, GArlington wrote:

    >
    > > > On Aug 28, 4:39*pm, Zilla wrote:

    >
    > > > > I'm trying to write a client/server app where I can do the following:
    > > > > - 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.

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

    >
    > > 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.- Hide quotedtext -

    >
    > > - 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.- Hide quoted text -
    >
    > - Show quoted text -


    I'm sorry, it's a variation of my #1 case.

  6. Re: Updating client's port information

    On Aug 28, 9:51*am, Zilla wrote:

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

  7. Re: Updating client's port information

    On Aug 28, 6:55*pm, Zilla wrote:
    > On Aug 28, 12:51*pm, Zilla wrote:
    >
    >
    >
    > > On Aug 28, 12:26*pm, Zilla wrote:

    >
    > > > On Aug 28, 12:03*pm, GArlington wrote:

    >
    > > > > On Aug 28, 4:39*pm, Zilla wrote:

    >
    > > > > > I'm trying to write a client/server app where I can do the following:
    > > > > > - 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.

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

    >
    > > > 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.- Hide quoted text -

    >
    > > > - 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.- Hide quoted text -

    >
    > > - Show quoted text -

    >
    > I'm sorry, it's a variation of my #1 case.


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

  8. Re: Updating client's port information

    On Aug 29, 12:32*am, David Schwartz wrote:
    > On Aug 28, 9:51*am, Zilla wrote:
    >
    > > ...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


    BTW: to "advertise" available ports it is common to use UDP [broadcast/
    multicast]...

  9. Re: Updating client's port information

    On Aug 28, 7:32*pm, David Schwartz wrote:
    > On Aug 28, 9:51*am, Zilla wrote:
    >
    > > ...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


    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?

  10. Re: Updating client's port information

    On Aug 29, 6:20*am, GArlington wrote:
    > On Aug 28, 6:55*pm, Zilla wrote:
    >
    >
    >
    >
    >
    > > On Aug 28, 12:51*pm, Zilla wrote:

    >
    > > > On Aug 28, 12:26*pm, Zilla wrote:

    >
    > > > > On Aug 28, 12:03*pm, GArlington wrote:

    >
    > > > > > On Aug 28, 4:39*pm, Zilla wrote:

    >
    > > > > > > I'm trying to write a client/server app where I can do the following:
    > > > > > > - 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.

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

    >
    > > > > 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 clientis
    > > > > 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.- Hide quoted text -

    >
    > > > > - 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.- Hide quotedtext -

    >
    > > > - Show quoted text -

    >
    > > I'm sorry, it's a variation of my #1 case.

    >
    > 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...- Hide quoted text -
    >
    > - 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.

  11. Re: Updating client's port information

    On Aug 29, 6:22*am, GArlington wrote:
    > On Aug 29, 12:32*am, David Schwartz wrote:
    >
    >
    >
    >
    >
    > > On Aug 28, 9:51*am, Zilla wrote:

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

    >
    > BTW: to "advertise" available ports it is common to use UDP [broadcast/
    > multicast]...- Hide quoted text -
    >
    > - Show quoted text -


    Ok, I'll look into multicasting since I don't necessarily want to
    broadcast.

  12. Re: Updating client's port information

    Zilla wrote:
    > On Aug 28, 7:32*pm, David Schwartz wrote:
    >> On Aug 28, 9:51*am, Zilla wrote:
    >>
    >> > ...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

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


    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.

  13. Re: Updating client's port information

    On Aug 29, 12:45*pm, Jim Logajan wrote:
    > Zilla wrote:
    > > On Aug 28, 7:32*pm, David Schwartz wrote:
    > >> On Aug 28, 9:51*am, Zilla wrote:

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

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

    >
    > 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.- Hide quoted text -
    >
    > - 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?"

  14. Re: Updating client's port information

    On Aug 29, 1:28*pm, Zilla wrote:
    > On Aug 29, 12:45*pm, Jim Logajan wrote:
    >
    >
    >
    >
    >
    > > Zilla wrote:
    > > > On Aug 28, 7:32*pm, David Schwartz wrote:
    > > >> On Aug 28, 9:51*am, Zilla wrote:

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

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

    >
    > > 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.- Hidequoted text -

    >
    > > - 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?"- Hide quoted text -
    >
    > - 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.

  15. Re: Updating client's port information

    On Aug 29, 1:55*pm, Zilla wrote:
    > On Aug 29, 1:28*pm, Zilla wrote:
    >
    >
    >
    >
    >
    > > On Aug 29, 12:45*pm, Jim Logajan wrote:

    >
    > > > Zilla wrote:
    > > > > On Aug 28, 7:32*pm, David Schwartz wrote:
    > > > >> On Aug 28, 9:51*am, Zilla wrote:

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

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

    >
    > > > 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.- Hide quoted text -

    >
    > > > - 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?"- Hide quoted text -

    >
    > > - 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.- Hide quoted text -
    >
    > - 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.

  16. Re: Updating client's port information

    In article
    ,
    Zilla 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, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  17. Re: Updating client's port information

    On Aug 29, 1:05*pm, Zilla wrote:
    > On Aug 29, 6:20*am, GArlington wrote:
    >
    >
    >
    > > On Aug 28, 6:55*pm, Zilla wrote:

    >
    > > > On Aug 28, 12:51*pm, Zilla wrote:

    >
    > > > > On Aug 28, 12:26*pm, Zilla wrote:

    >
    > > > > > On Aug 28, 12:03*pm, GArlington wrote:

    >
    > > > > > > On Aug 28, 4:39*pm, Zilla wrote:

    >
    > > > > > > > I'm trying to write a client/server app where I can do the following:
    > > > > > > > - 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.

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

    >
    > > > > > 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.- Hide quoted text -

    >
    > > > > > - 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.- Hide quoted text -

    >
    > > > > - Show quoted text -

    >
    > > > I'm sorry, it's a variation of my #1 case.

    >
    > > 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...- Hide quoted text -

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


    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?

  18. Re: Updating client's port information

    On Sep 1, 9:08*am, GArlington wrote:
    > On Aug 29, 1:05*pm, Zilla wrote:
    >
    >
    >
    >
    >
    > > On Aug 29, 6:20*am, GArlington wrote:

    >
    > > > On Aug 28, 6:55*pm, Zilla wrote:

    >
    > > > > On Aug 28, 12:51*pm, Zilla wrote:

    >
    > > > > > On Aug 28, 12:26*pm, Zilla wrote:

    >
    > > > > > > On Aug 28, 12:03*pm, GArlington wrote:

    >
    > > > > > > > On Aug 28, 4:39*pm, Zilla wrote:

    >
    > > > > > > > > I'm trying to write a client/server app where I can do the following:
    > > > > > > > > - 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.

    >
    > > > > > > > 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 thereon the
    > > > > > > > processing thread is communicating with the client and main server
    > > > > > > > carries on listening/waiting for new connections...

    >
    > > > > > > 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.- Hide quoted text -

    >
    > > > > > > - 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.- Hide quoted text -

    >
    > > > > > - Show quoted text -

    >
    > > > > I'm sorry, it's a variation of my #1 case.

    >
    > > > 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...- Hide quoted text -

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

    >
    > 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?- Hide quoted text -
    >
    > - 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.

  19. Re: Updating client's port information

    On Sep 4, 9:26*am, Zilla wrote:

    > 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


  20. Re: Updating client's port information

    On Sep 4, 2:19*pm, David Schwartz wrote:
    > On Sep 4, 9:26*am, Zilla wrote:
    >
    > > 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


    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.

+ Reply to Thread
Page 1 of 2 1 2 LastLast