Pipe Server

The Pipe Server plugin simplifies the process of testing named pipe communications. It allows developers to quickly create a server-side pipe that client applications can connect to, streamlining setup and reducing the time and effort required for testing and debugging.

Capabilities

Required

org.jancy.io.win.named-pipe

Allows users to create Windows named pipe servers.

Basic Setup

  1. In IO Ninja, click the “New Session” dropdown and select a new “Pipe Server” session

_images/pipe-server-new-session.png

  1. Enter the name of your pipe in the “Pipe:” field.

Since this is a local pipe, it takes the the following form: \\.\pipe\my-pipe-server. If the \\.\pipe\ prefix is not used, it will be added, so if you type my-pipe-server, it will be \\.\pipe\my-pipe-server.

Please see Microsoft’s documentation on pipe names for more information.

_images/pipe-server-pipe-name.png

  1. Press the “Start Listening” button, to the right of the “Pipe:” field.

_images/pipe-server-listening.png

  1. See connected clients in the “Active client(s)” section of the Control pane.

Unlike TCP or UDP, connections over NPFS (Named Pipe File System) do not provide any identifying information about the client that connects to a pipe. To address this, we rely on opaque identifiers that are guaranteed to be unique for each client connection at any given time. Technically, these identifiers are operating system file handles associated with the server-side of the named pipe—specifically, the HANDLE values returned by CreateNamedPipe.

This Active client(s) list is not only for checking who is connected. When we select an item here, we select who are we talking to when we use the Transmit pane.

_images/pipe-server-clients.png

  1. In the Transmit pane, send messages as required.

_images/pipe-server-transmit.png

  1. Analyze messages received from clients in the log.

_images/pipe-server-replies.png

  1. In the Control pane, use “Client log filter:” to select which client you want to see messages from.

_images/pipe-server-filter.png

Settings

_images/pipe-server-settings.png

Setting

Description

Default

Pipe name

Specify the pipe name to listen on.

Message mode

Enable or disable “message mode”. In “message mode”, the data written to the pipe is treated as distinct messages, preserving boundaries between write operations.

False

Read parallelism

Maximum number of read requests to submit to tdevmon at the same time. Having more than one pending read at a time helps prevent notification loss in IO-intensive scenarios (after filling one user buffer, tdevmon can immediately switch to the next one without any waiting). Increasing this number beyond 4 usually won’t yield any extra gains.

4

Read block size (B)

The size of each individual read block submitted to tdevmon.

4KB

RX buffer size (B)

The full size of the incoming data (RX) buffer. Affects read throughput.

16KB

TX buffer size (B)

The full size of the outbound data (TX) buffer. Affects write throughput.

16KB

Keep read block size

Don’t merge read blocks in RX buffer. Incoming data blocks coming in quick succession can be merged together so that IO Ninja writes them to log as a whole. When this option is set to True, blocks are written to the log without merging, i.e., exactly as they are received from the underlying transport..

False

Keep write block size

Don’t merge write blocks in TX buffer. Outbound data blocks sent in quick succession can be merged together before submission to the underlying transport. When this option is set to True, blocks are submitted to the transport without merging, i.e., exactly as they are sent by the Transmit or Script panes..

False

RX buffer full notifications

Toggle warnings in log about the incoming data (RX) buffer getting full.

False

See Also