none
NamedPipeServerStream - Pipe buffer size RRS feed

  • Question

  • Hi,

    How can I know how many bytes are currently in the buffer? i.e. bytes that the server wrote and the client did not read?

    BTW, PipeStream class does not support the Length & Position properties.

    Thanks

    Yaron

    • Moved by Bob Shen Monday, April 8, 2013 8:28 AM
    Friday, April 5, 2013 11:38 PM

Answers

All replies

  • Hi Yaron,

    I would like to redirect you to appropriate forum for better responses.  


    Bob Shen
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, April 8, 2013 8:28 AM
  • Hi,

    How can I know how many bytes are currently in the buffer? i.e. bytes that the server wrote and the client did not read?

    BTW, PipeStream class does not support the Length & Position properties.

    Thanks

    Yaron

    Hi Yaron,

    But these pipeStream have:

            System.IO.Pipes.AnonymousPipeClientStream
            System.IO.Pipes.AnonymousPipeServerStream
            System.IO.Pipes.NamedPipeClientStream
            System.IO.Pipes.NamedPipeServerStream

    And the PipeStream is a abstract class, you cannot make an instance of it.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Tuesday, April 23, 2013 2:50 PM
    Moderator
  • Ok, so let assume that I use the NamedPipeServerStream object, still how can I know how many bytes are currently in the buffer?

    Yaron

    Tuesday, April 23, 2013 3:17 PM
  • Ok, so let assume that I use the NamedPipeServerStream object, still how can I know how many bytes are currently in the buffer?

    Yaron

    Please try the length - Position.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Thursday, April 25, 2013 12:15 PM
    Moderator
  • When you go to thelength property Documentation under  'System.IO.Pipes.NamedPipeServerStream', you will find the next comment

    "The PipeStream class does not support the Length property". This is because NamedPipeServerStream does not implement this property.


    • Edited by Yaron.Cohen Thursday, April 25, 2013 12:53 PM
    Thursday, April 25, 2013 12:53 PM
  • Hi Yaron,

    Yes, it is.

    Anyway, based on your description, it seems that you need to implement read and write a name pipe stream, so would you like to try this sample: http://www.codeproject.com/Tips/441841/Csharp-Named-Pipes-with-Async 

    http://www.codeproject.com/Tips/492231/Csharp-Async-Named-Pipes

    This is because: http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/10324cb1-09ad-4992-90b7-8c0406fd5b1c 

    "This is entirely by design.  You'll need to use PipeStream.BeginRead() instead."

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Sunday, April 28, 2013 10:29 AM
    Moderator
  • Actually when you think about it, NamedPipe works like a NetworkStream so it'll also have all the limitations there. You never know how much data is already there unless you actually need it.

    Read until .IsMessageComplete returns false could be good enough, but I personally will use the good old practice to read data on a background thread into application's buffer until .Read() returns 0 for data read.

    Monday, April 29, 2013 3:56 AM
    Answerer
  • The NamedPipeServerStream is initialized with buffer size. Once the buffer is full (i.e. the server writes and the client don't read) the server write function stuck till the client read data from the buffer. This means that the server must have a way to know what is the buffer size.
    Monday, April 29, 2013 6:05 AM
  • You can get the .InBufferSize (note that 0 means automatic adjusted, not "working without buffer), just that you cannot get how many bytes of data is already there.
    Monday, April 29, 2013 6:13 AM
    Answerer
  • Hi There,
    Do you have any update?

    Thanks.
    Best regards,

    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Saturday, May 4, 2013 2:25 PM
    Moderator
  • Actually, I dont see how implementing the read and write functions will help me here. How it will help me as a server to know how many free bytes have have in the named pipe buffer?

    Yaron

    Sunday, May 5, 2013 6:05 AM
  • Hi Yaron,

    >>How it will help me as a server to know how many free bytes have have in the named pipe buffer?

    Please just forget the the unread bytes numbers. When you don't know the unread bytes, you can still read and write the data.

    >>I dont see how implementing the read and write functions will help me here. 

    Please check the my reply at Sunday, April 28, 2013 10:29 AM. It mentioned a few code samples.

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Sunday, May 5, 2013 6:43 AM
    Moderator
  • Just read the pipe into your own private buffer when there is data.

    Now since you own your private buffer, you should be able to tell how much data is written to it.

    Monday, May 6, 2013 2:08 AM
    Answerer
  • Hi Mike,

    I checked the code samples you supplied, but I don't understand how it helps me with the original question "How can I know how many bytes are currently in the buffer? i.e. bytes that the server wrote and the client did not read?"
    What I am missing here?

    Thanks
    Yaron

    Monday, May 6, 2013 6:11 AM
  • Hi,

    What do you mean by "read the pipe into your own private buffer"? Which private buffer?

    Thanks
    Yaron

    Monday, May 6, 2013 6:12 AM
  • HiYaron,

    >>but I don't understand how it helps me with the original question "How can I know how many bytes are currently in the buffer? i.e. bytes that the server wrote and the client did not read?"

    Yes, it is. My suggestion is: donot try to get the unread bytes number. Your root purpose is read the data, if you know a way can read the data without the unread bytes number, do you still care the number?

    Best regards,


    Mike Feng
    MSDN Community Support | Feedback to us
    Develop and promote your apps in Windows Store
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.

    Monday, May 6, 2013 6:28 AM
    Moderator
  • I will try to explain my issue here.

    I have a thread that handle many pipes (Few hundreds). If the server try to write to the pipe and the pipe is full, it will be blocked on this call (i.e. can not continue to write to other pipes) untill the client will read some data. I don't like to use BeginWrite since it make the entier soution very complication while working with the completion procedure and trying to keep the original writing order.

    So I need a way to know "How can I know how many bytes are currently in the buffer" in order to move to the next pipe if the current is full.

    Thanks

    Yaron

    Monday, May 6, 2013 6:51 AM
  • Say, you declare a Queue<byte> q member as private buffer. Now you create a background thread to loop the pipeStream.Read() so it'll Enqueue() any data in the pipe stream as soon as it hits there.

    Now you can use q.Count to see how many data you received and use q.Dequeue() to remove the foremost item on queue.

    Due to performance reason you may want to use other type of container as buffer, though. (But will require varying amount of programming work. For example, use plain byte[] with static methods offered by System.Buffer class, or to chain the NamedPipeServerStream with MemoryStream, etc.)

    Monday, May 6, 2013 7:23 AM
    Answerer
  • I will try to explain my issue here.

    I have a thread that handle many pipes (Few hundreds). If the server try to write to the pipe and the pipe is full, it will be blocked on this call (i.e. can not continue to write to other pipes) untill the client will read some data. I don't like to use BeginWrite since it make the entier soution very complication while working with the completion procedure and trying to keep the original writing order.

    So I need a way to know "How can I know how many bytes are currently in the buffer" in order to move to the next pipe if the current is full".

    I don't think (please correct me if I am wrong) that you suggestion will help here.

    Thanks

    Yaron

    Monday, May 6, 2013 7:43 AM
  • In your case, you'll have to 1) create a private buffer, 2) Set the buffer size for each pipe to a very low number (not be "0" here because it means the size is automatically adjusted, most probably the max estimated size of a data chunk to be readed), and 3) have a background thread to drain data from pipe to that private buffer, for each pipe.

    Now change your logic to do the "Read" action from your private buffer instead of the pipe itself.

    For outgoing pipes the process is similar, just that the background thread now reads from the buffer to the pipe and your process now writes to the buffer instead.

    No async call is need in this method.

    Monday, May 6, 2013 9:58 AM
    Answerer
  • Our current solution is similar to the one you just suggested. The prolem is that we have many pipes to serve (thousand). Since that the thread count is limited, I can not let it be stuck while trying to pop items from the private buffer and write them to the named pipe
    Monday, May 6, 2013 11:17 AM
  • If that's your concern, you'll really need to switch to async method + threadpool method then, which would mean you probably need to rewrite a large part of code to realign the logic. (ThreadPool don't work well with blocking calls. Your pool would be depleted soon because threads are not returning)

    Btw, I somehow remember that having large number of opening pipe handle is not a good idea either. There's something like 2048 on Workstation SKU and 8192 on Server SKU limit on concurrrent open handles (I can't find corresponding documentation now to check if I remembered it correctly, though).

    Tuesday, May 7, 2013 1:45 AM
    Answerer
  • Thanks for your help

    Yaron

    • Marked as answer by Yaron.Cohen Tuesday, May 7, 2013 6:57 AM
    Tuesday, May 7, 2013 6:57 AM