0

Following this sample, I can set nMaxInstances.
How can I know when the number of named pipe client's connections to exceed the maximum allowed (both service and client)?

Thinh Nguyen Van
  • 113
  • 2
  • 18
  • I'm not sure what you are asking. Do you want to know how to detect when your server is at max capacity? Or are you trying to increase the max capacity once it has been reached? Or what exactly are you asking for? – Remy Lebeau Sep 19 '17 at 03:14
  • @RemyLebeau: How to detect when my server is at max capacity? I edited. – Thinh Nguyen Van Sep 19 '17 at 03:24
  • @RemyLebeau Can't be the latter, as you can't do it. – user207421 Sep 19 '17 at 03:24
  • @EJP I know that, but maybe the OP didn't. That is why I asking for clarification about the question. – Remy Lebeau Sep 19 '17 at 03:28
  • 1
    @ThinhNguyenVan your question is still unclear. Do you want the server to know when it can't accept more clients? Or do you want the client to know that it can't connect to a server because it is already at its max capacity? Again, please be more clear about your question. – Remy Lebeau Sep 19 '17 at 03:30

1 Answers1

4

When you've reached the maximum number of concurrent instances, creating the excess instance will fail.

Microsoft haven't bothered to document their error codes for CreateNamedPipe(), so it is impossible to be more specific.

EDIT @eryksun has kindly provided the information that the error is ERROR_PIPE_BUSY. This is stated clearly in my OS/2 manual from 1989, but it seems to have got lost in the NT project.

user207421
  • 305,947
  • 44
  • 307
  • 483
  • Note that this won't happen unless there is a bug in your program. – Harry Johnston Sep 19 '17 at 03:15
  • @HarryJohnston it will happen if you define the pipe to have *N* instances and receive *N* connections, all of which remain open, while you attempt to create the *N+1th* instance. Whether that's a 'bug' or a legitimate way to detect the limit is open to interpretation. Personally I would rely on the OS to count the instances for me, rather than trying to maintain my own count. – user207421 Sep 19 '17 at 03:23
  • 4
    Even though it's undocumented, for completeness the error in this case is `ERROR_PIPE_BUSY`, i.e. all pipe instances are busy. It's the same error as for the client-side `CreateFile` when there are no listening instances. In the NT API, the `NtCreateNamedPipeFile` system call returns `STATUS_INSTANCE_NOT_AVAILABLE`, i.e. the maximum named pipe instance count has been reached. And for the client the `NtCreateFile` system call returns `STATUS_PIPE_NOT_AVAILABLE`, i.e. an instance of a named pipe cannot be found in the listening state. – Eryk Sun Sep 19 '17 at 03:47
  • @eryksun Well done. I did know all this stuff at one stage, but it's 25 years since I looked at it. The documentation has got even worse since then. – user207421 Sep 19 '17 at 04:44
  • Typically I'd expect to create all *N* instances during process initialization, making counting trivial. But perhaps there are scenarios where that's inconvenient, I haven't given it a lot of thought. – Harry Johnston Sep 19 '17 at 05:31
  • @HarryJohnston Microsoft clearly expect you to engage in a create/connect loop, and in that case you have to decrement the count when you close one, which introduces a concurrency issue. – user207421 Sep 19 '17 at 05:34
  • I disagree with your premise; a create/connect loop is not the most appropriate approach when you're limiting the number of instances. IIRC, most of the sample code uses create/connect, but that's because they're *not* limiting the number of instances. However, this is all tangential to your answer, so perhaps I shouldn't have brought it up. – Harry Johnston Sep 19 '17 at 05:39
  • @HarryJohnston I don't have any premiss about what is 'most appropriate' for you to disagree with. I stated what Microsoft clearly expect, as exhibited in their sample code. Take it up with Microsoft here, not with me. – user207421 Feb 17 '20 at 19:07
  • @user207421, just because Microsoft demonstrate one particular method does not mean that they "expect" you to use that method willy-nilly regardless of whether or not it is appropriate for your use-case! – Harry Johnston Feb 17 '20 at 21:47