Multiple pipes
-
A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients. All instances of a named pipe share the same pipe name, but each instance has its own buffers and handles, and provides a separate conduit for client-server communication. The use of instances enables multiple pipe clients to use the same named pipe simultaneously. Can anyone point me in the right direction for creating multiple named pipe of the same name and using multiple clients over it. i.e how do a client distinguish which pipe to connect if we have two pipes created in two process with the same name.
-
A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients. All instances of a named pipe share the same pipe name, but each instance has its own buffers and handles, and provides a separate conduit for client-server communication. The use of instances enables multiple pipe clients to use the same named pipe simultaneously. Can anyone point me in the right direction for creating multiple named pipe of the same name and using multiple clients over it. i.e how do a client distinguish which pipe to connect if we have two pipes created in two process with the same name.
-
One the Win32 platform, in theory instanses of the named pipe could be distinguished via handles. One the UNIX platform, consider, for example, a file descriptor. Kuphryn
-
I am sorry but if two different processes create a named pipe with the same name how can the client differ in the two? A client would not have handles to any.
-
A named pipe is a named, one-way or duplex pipe for communication between the pipe server and one or more pipe clients. All instances of a named pipe share the same pipe name, but each instance has its own buffers and handles, and provides a separate conduit for client-server communication. The use of instances enables multiple pipe clients to use the same named pipe simultaneously. Can anyone point me in the right direction for creating multiple named pipe of the same name and using multiple clients over it. i.e how do a client distinguish which pipe to connect if we have two pipes created in two process with the same name.
What you're planning is not possible. Two different pipe server processes can not create a named pipe with the same name. From MSDN: Each named pipe has a unique name that distinguishes it from other named pipes in the system's list of named objects. The way named pipes work is pretty straight-forward. Firstly, you have a pipe server process that is responsible for creating pipe instances. The function
CreateNamedPipecreates either the first instance of a named pipe, or a new instances of an existing pipe. Like MSDN states, each of these instances have their own buffers and handles. When the first instance of the pipe is created, this pipe-name becomes unique to this process. No other pipe server process can create a named pipe with the same name. Attempting such would result in an error code (ERROR_BAD_PIPE or ERROR_INVALID_HANDLE). After the pipe instance is created,ConnectNamedPipeprepares this created pipe instance for client connections. Each instance of a named pipe MUST be prepared by the server before a connection from a client is possible. This server process can then, as it sees fit, create and prepare more instances of the same pipe or instances of differently-named pipes. Clients can then useCallNamedPipeto connect, transact and disconnect from an (undetermined) instance of the named pipe. If the server has run out of free pipe instances, an error value is returned (ERROR_PIPE_BUSY), or optionally, the function can wait until a pipe instance becomes available. The clients can not distinguish which pipe instance they are connecting to. All instances of a named pipe are similar by outside aspects, i.e. they provide precisely the similar type of services. If you need a type A pipe for one client and type B pipe for another client, you must create two named pipes, which both have a seperate unique name. See the idea ? Server creates and initializes named pipe instances (one or more instances of the same named pipe, and/or one or more instances of several named pipes), and clients request an access to these instances for data transfer, identifying the requested named pipe by it's name. But the clients can not determine the specific instance of the pipe they wish to connect to. This is determined by the server. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible. -
What you're planning is not possible. Two different pipe server processes can not create a named pipe with the same name. From MSDN: Each named pipe has a unique name that distinguishes it from other named pipes in the system's list of named objects. The way named pipes work is pretty straight-forward. Firstly, you have a pipe server process that is responsible for creating pipe instances. The function
CreateNamedPipecreates either the first instance of a named pipe, or a new instances of an existing pipe. Like MSDN states, each of these instances have their own buffers and handles. When the first instance of the pipe is created, this pipe-name becomes unique to this process. No other pipe server process can create a named pipe with the same name. Attempting such would result in an error code (ERROR_BAD_PIPE or ERROR_INVALID_HANDLE). After the pipe instance is created,ConnectNamedPipeprepares this created pipe instance for client connections. Each instance of a named pipe MUST be prepared by the server before a connection from a client is possible. This server process can then, as it sees fit, create and prepare more instances of the same pipe or instances of differently-named pipes. Clients can then useCallNamedPipeto connect, transact and disconnect from an (undetermined) instance of the named pipe. If the server has run out of free pipe instances, an error value is returned (ERROR_PIPE_BUSY), or optionally, the function can wait until a pipe instance becomes available. The clients can not distinguish which pipe instance they are connecting to. All instances of a named pipe are similar by outside aspects, i.e. they provide precisely the similar type of services. If you need a type A pipe for one client and type B pipe for another client, you must create two named pipes, which both have a seperate unique name. See the idea ? Server creates and initializes named pipe instances (one or more instances of the same named pipe, and/or one or more instances of several named pipes), and clients request an access to these instances for data transfer, identifying the requested named pipe by it's name. But the clients can not determine the specific instance of the pipe they wish to connect to. This is determined by the server. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible. -
Thanks for the response. I will see how I can work this out...... Can you please clarify what nDefaultTimeOut parameter stands for in CreateNamedPipe call and what is its connection to WaitNamedPipe etc call(s) if any.
This parameter of the call specifies the time, in milliseconds, that a client connecting to the pipe will wait for when no free pipe instances are available. You can determine how long the client side function will wait before issuing a time-out. It can be a certain time in milliseconds, the default wait time specified by the server, or it can wait forever. Here, the default wait time specified by the server is the key phrase. This time period is determined by the
nDefaultTimeOutparameter. Each pipe instance created byCreateNamedPipemust specify the same time-out value. This value is supplied only so that clients, which useWaitNamedPipeorCallNamedPipefunctions to connect to the named pipe, know how long they should wait, by default, before issuing a time-out error. If, during this time period, a pipe instance becomes available (the server creates a new instance or some other client disconnects from one pipe instance), then the client-side pipe function will connect to this available pipe. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible. -
This parameter of the call specifies the time, in milliseconds, that a client connecting to the pipe will wait for when no free pipe instances are available. You can determine how long the client side function will wait before issuing a time-out. It can be a certain time in milliseconds, the default wait time specified by the server, or it can wait forever. Here, the default wait time specified by the server is the key phrase. This time period is determined by the
nDefaultTimeOutparameter. Each pipe instance created byCreateNamedPipemust specify the same time-out value. This value is supplied only so that clients, which useWaitNamedPipeorCallNamedPipefunctions to connect to the named pipe, know how long they should wait, by default, before issuing a time-out error. If, during this time period, a pipe instance becomes available (the server creates a new instance or some other client disconnects from one pipe instance), then the client-side pipe function will connect to this available pipe. -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.Thanks a lot!!! One more question....
LPTSTR lpszPipename = "\\\\.\\pipe\\mynamedpipe"; HANDLE hEvents = CreateEvent(NULL, TRUE, TRUE, NULL); OVERLAPPED Overlap; Overlap.hEvent = hEvents; Pipe.hPipeInst = CreateNamedPipe( lpszPipename, // pipe name PIPE_ACCESS_DUPLEX | // read/write access FILE_FLAG_OVERLAPPED, // overlapped mode PIPE_TYPE_MESSAGE | // message-type pipe PIPE_READMODE_MESSAGE | // message-read mode PIPE_WAIT, // blocking mode INSTANCES, // number of instances BUFSIZE, // output buffer size BUFSIZE, // input buffer size PIPE_TIMEOUT, // client time-out NULL); // no security attributes while (1) { BOOL bSuccess = ::ConnectNamedPipe(m_hPipe, lpOverlapped); dwWait = WaitForMultipleObjects( INSTANCES, // number of event objects hEvents, // array of event objects FALSE, // does not wait for all INFINITE); // waits indefinitely switch(dwWait) { case ..//handle the client.. } }How can I create a new pipe instance using CreateNamedPipe for every new client. -
Thanks a lot!!! One more question....
LPTSTR lpszPipename = "\\\\.\\pipe\\mynamedpipe"; HANDLE hEvents = CreateEvent(NULL, TRUE, TRUE, NULL); OVERLAPPED Overlap; Overlap.hEvent = hEvents; Pipe.hPipeInst = CreateNamedPipe( lpszPipename, // pipe name PIPE_ACCESS_DUPLEX | // read/write access FILE_FLAG_OVERLAPPED, // overlapped mode PIPE_TYPE_MESSAGE | // message-type pipe PIPE_READMODE_MESSAGE | // message-read mode PIPE_WAIT, // blocking mode INSTANCES, // number of instances BUFSIZE, // output buffer size BUFSIZE, // input buffer size PIPE_TIMEOUT, // client time-out NULL); // no security attributes while (1) { BOOL bSuccess = ::ConnectNamedPipe(m_hPipe, lpOverlapped); dwWait = WaitForMultipleObjects( INSTANCES, // number of event objects hEvents, // array of event objects FALSE, // does not wait for all INFINITE); // waits indefinitely switch(dwWait) { case ..//handle the client.. } }How can I create a new pipe instance using CreateNamedPipe for every new client.Named pipes should only be used when you have at least some approximation of how many clients there will be connecting. If you have no idea how many, then I would consider using sockets as a better alternative, for efficiency, safety and listening reasons. Afterall, when the server creates one listening socket, each client can connect to that one and the server will worry about establishing a connection on a seperate socket. But if you must use pipes, then I suggest that you firstly create just one pipe instance. Always when a client connects to this pipe (handle client connecting), the server will call a function that creates a new pipe instance. This follows the logic: "You don't know how many clients there will be, so always keep at least one pipe instance available for a new client." -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.
-
Named pipes should only be used when you have at least some approximation of how many clients there will be connecting. If you have no idea how many, then I would consider using sockets as a better alternative, for efficiency, safety and listening reasons. Afterall, when the server creates one listening socket, each client can connect to that one and the server will worry about establishing a connection on a seperate socket. But if you must use pipes, then I suggest that you firstly create just one pipe instance. Always when a client connects to this pipe (handle client connecting), the server will call a function that creates a new pipe instance. This follows the logic: "You don't know how many clients there will be, so always keep at least one pipe instance available for a new client." -Antti Keskinen ---------------------------------------------- The definition of impossible is strictly dependant on what we think is possible.