Can WSK(Winsock Kernel) support listen backlog?

Dear friends,

I have two questions about MS WSK(Winsock kernel) .

Q1:
WSK TCP bind(listen server) socket has no backlog queue.
So, if two or more connection requests occure simultaneously then the listen server socket ignores old connections.
Do you have solution to support backlog on the WSK listen socket?

Q2:
WSKsend function waits for send operation until all data has been sent.
We need to send data with non-blocking mode.
Do you have solution to peek the send buffer empty or not

Thanks.

I’d have to go refresh my memory on the exact details of inbound
connection events but as I remember you get notification, typically at
DISPATCH_LEVEL, of the incoming connection via the WskAcceptEvent handler,
and you get the new connection socket with that event. It might be
possible you only get a single WskAcceptEvent event at a time on a
listening socket (as in accepts are perhaps serialized, even if RSS has
spread incoming connection packets across multiple processors). Are you
talking about a case where you don’t use callback events? It looks like
you can also initiate a bunch of WskAccept calls, and they pend,
completing the supplied IRP when the connection happens, which seems
essentially like a backlog, which you control.

As far as sends being blocking, I’m puzzled at what you are talking about.
You give an IRP with the send, the send returns with the I/O initiated,
and you get IRP completion when the completion happens. That’s an
asynchronous process. You DO have to not reuse the send buffers until the
I/O completes, as the hardware may be doing DMA from your send buffers
(zero copy send) until completion happens.

There is a pretty nice WSK sample with the WDK that I think covers most
cases. Due to your Q2 about non-blocking, I’m guessing your missing
something about kernel async I/O in general.

Most (all?) of the WSK functions take an IRP as a means of asynchronous
completion notification.

Jan

On 1/19/15, 7:15 AM, “xxxxx@gmail.com” wrote:

>Dear friends,
>
>I have two questions about MS WSK(Winsock kernel) .
>
>Q1:
>WSK TCP bind(listen server) socket has no backlog queue.
>So, if two or more connection requests occure simultaneously then the
>listen server socket ignores old connections.
>Do you have solution to support backlog on the WSK listen socket?
>
>Q2:
>WSKsend function waits for send operation until all data has been sent.
>We need to send data with non-blocking mode.
>Do you have solution to peek the send buffer empty or not
>
>Thanks.
>
>
>—
>NTDEV is sponsored by OSR
>
>Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
>OSR is HIRING!! See http://www.osr.com/careers
>
>For our schedule of WDF, WDM, debugging and other seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer

Dear jan,

Thank you for your prompt answer.

  1. listen backlog problem

Yes, I don’ t use callback event.
Let me try WskAcceptEvent handler.

According to your answer, there is “bunch of WskAccept”.
What does it mean?
Can I slove this problem without using WskAcceptEvent handler?

  1. send blocking problem

Yes, basically WSKsend itself is blocking mode.
But my question is how to avoid block for second WSKsend request by another thread during first WSKsend not finished yet.
During sending big buffer(like 1 MB over) with very slow network bandwith(like 1kbps), the second send should wait for long time.
So I need to peek the send operation busy or not before send.
I will make this peek operation using very short KeWaitForXXXObject timeout after WSKsend.
Do you have another ieda?

Thanks

I would personally probably use a WskAcceptEvent handler, but I believe
you can initiate a bunch of WskAccept calls and they will return pending,
and complete when a connection happens. As they complete, you would want
to replenish the supply of pending requests, so there is always one
available when a connection request comes in. As noted at
http://msdn.microsoft.com/en-us/library/windows/hardware/ff571109(v=vs.85).
aspx, a pointer to your new accepted socket is passed to the IRP
completion in IoStatus.Information.

So tell me how you think WSKSend is blocking? I don’t think any of the WSK
functions as blocking, they all take an IRP for completion notification.

You call WSKSend with the buffers and completion IRP, it either completes
right way or else it returns right away with a status of pending, it
should not block the calling thread. You can call WSKSend from
DISPATCH_LEVEL, where blocking the execution thread is not possible. If
the call to WSKSend completed right way, the IRP completion would have
already happened, and you can reuse the buffer. If the call returned
pending, IRP completion will happen in the future (at DISPATCH_LEVEL), and
the buffer can’t be modified until you get completion notification.
Multiple threads can be initiating sends with WSKSend on a single socket,
although the ordering of the data stream from the multiple threads will be
indeterminate because it’s indeterminate which threads get scheduled. The
buffers from two WSKSends, initiated from different threads, will not be
interleaved, so all the data for each WSKSend will be sent together in the
TCP stream, even if the buffer list is made of multiple fragments. None of
the threads calling WSKSend should block, although would expend the
WSKSend to return pending.

No you don’t need to peek to see if send is busy or not, you initiate the
send, and sometime later, you will be notified when it’s done and what the
status was. The call to WSKSend will return quickly (and quickly is
defined as it might have small delays caused by waiting on spinlocks to
connection instance data). If there are many things ahead of it in the
queue, it may be a while before completion notification happens. You might
want multiple threads, that wait for completion of the send, or you might
have a single thread (or threads) that manage multiple asynchronous
requests at once. When you get the IRP completion callback, you have the
CPU again, and you can do some more processing (at DISPATCH_LEVEL) or you
can queue a work item for a PASSIVE_LEVEL thread pool, or you can wake up
a thread that’s waiting for the completion.

Jan

On 1/20/15, 1:13 AM, “xxxxx@gmail.com” wrote:

>Dear jan,
>
>Thank you for your prompt answer.
>
>1. listen backlog problem
>
>Yes, I don’ t use callback event.
>Let me try WskAcceptEvent handler.
>
>According to your answer, there is “bunch of WskAccept”.
>What does it mean?
>Can I slove this problem without using WskAcceptEvent handler?
>
>2. send blocking problem
>
>Yes, basically WSKsend itself is blocking mode.
>But my question is how to avoid block for second WSKsend request by
>another thread during first WSKsend not finished yet.
>During sending big buffer(like 1 MB over) with very slow network
>bandwith(like 1kbps), the second send should wait for long time.
>So I need to peek the send operation busy or not before send.
>I will make this peek operation using very short KeWaitForXXXObject
>timeout after WSKsend.
>Do you have another ieda?
>
>Thanks
>
>—
>NTDEV is sponsored by OSR
>
>Visit the list at: http://www.osronline.com/showlists.cfm?list=ntdev
>
>OSR is HIRING!! See http://www.osr.com/careers
>
>For our schedule of WDF, WDM, debugging and other seminars visit:
>http://www.osr.com/seminars
>
>To unsubscribe, visit the List Server section of OSR Online at
>http://www.osronline.com/page.cfm?name=ListServer