Is there an equivalent to TCP_NODELAY in IPV6 of WSK?

NTDEV
1

Hi,

I am porting my driver from TDI to WSK to support IPV6, but the current problem is that the small sending packets are always reformed as a bigger sending packet by the WSK subsystem, which is always a malfromed packet according to the view of WireShark. And this process leads to serious side effects in the runtime requirements.

So my question is that how to cancel the packet reforming operation of WSK subsystem and just send my original packets out (like the TCP_NODELAY in user mode Winsock2).

Thanks much in advance.

Joseph

2

According to MSDN, setting TCP_NODELAY or SO_SNDBUF=0 will disable Nagle algorithm in user mode Winsock2. Please see below:

"The TCP_NODELAY socket option is applied to disable the Nagle algorithm so that the small data packets are delivered to the remote host without delay.

You can change the amount of Winsock kernel buffer allocated to the socket using the SO_SNDBUF option (it is 8K by default). If necessary, Winsock can buffer significantly more than the SO_SNDBUF buffer size. In most cases, the send completion in the application only indicates the data buffer in an application send call is copied to the Winsock kernel buffer and does not indicate that the data has hit the network medium. The only exception is when you disable the Winsock buffering by setting SO_SNDBUF to 0."

But when it comes to WinSock Kernel, what should we do to implement it?

Joseph

3

> According to MSDN, setting TCP_NODELAY or SO_SNDBUF=0

SO_SNDBUF is much different from TCP_NODELAY.

The first delays sends (and coalesces the send() calls) till the send buffer will be full.

The second delays sends (and coalesces the send() calls) till some ACK will arrive from the receiving end.

The purpose of the first is to allow send() to be not-so-blocking or not-necessary-blocking.

The purpose of the second is to do on-the-wire packet coalescing.

The first one is implemented above TDI or WSK, so, your WSK client must implement the send buffer itself.

The second one is in the TCP core, governed by setsockopt() or some IOCTL to TCP stack. See WSHSMPLE sample from the WDK.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

4

Thank you Maxim, I would have a try and let you know the results.

5

Hi Maxim,

In my opinion, the second one is in user mode, I haven’t found how to implement it in Kernel mode, would you like to shed me some light?

Thanks.

Joseph

6

IOCTL from WSHSMPLE should also work in kmode.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.com

wrote in message news:xxxxx@ntdev…
> Hi Maxim,
>
> In my opinion, the second one is in user mode, I haven’t found how to implement it in Kernel mode, would you like to shed me some light?
>
> Thanks.
>
> Joseph
>