Liste des Groupes | Revenir à co vms |
On Sun, 29 Sep 2024 20:02:59 -0400, Arne Vajhøj wrote:It should not be a problem of copying a socket descriptor from oneOn 9/29/2024 7:43 PM, Lawrence D'Oliveiro wrote:Then it asks another process for a copy of that socket descriptor. PerhapsOn Sun, 29 Sep 2024 19:16:48 -0400, Arne Vajhøj wrote:>On 9/29/2024 6:57 PM, Lawrence D'Oliveiro wrote:>On Sun, 29 Sep 2024 10:46:12 -0400, Arne Vajhøj wrote:>And I don't understand the "put all the client context into shared>
memory" either. Are you saying that if socket descriptors are put in
shared memory then any process that map that memory can use those
sockets????
No, but the shared-memory context can contain an index into a table
of socket descriptors in private per-process memory. If the process
trying to server a client context does not actually have a socket
descriptor in the slot for that context, it can ask for one.
I still can't follow the idea.
>
Client X has a connection to server worker A. That means that A has
index 77 in shared memory that points to the socket descriptor for the
connection from X.
>
Worker B wants to serve X as well and it get index 77 from shared
memory. And then it does what?
Looks up its entry in its process-private copy of the array that
contains the socket descriptors, to see if it has its own valid fd for
that socket.
Yes. And if it does not then what?
there is one overall connection-management process that accepts all new
connections; if not, another worker that has that socket can pass it
along.
Les messages affichés proviennent d'usenet.