Winsock Kernel (WSK) support

We have a kernel driver with wsk connection socket running on one pc and another kernel driver with wsk Listener socket running on another pc.
We have configured the socket buffer to 32KB and sending/receiving the data with some 500ms delay between each send/receive.
We are opening and closing the socket for every send/receive.
It is observed that after some 20-30 mins the connections is getting break and the Listener socket (server) becomes unresponsive.

Is there any limit on the number of open/close socket on a particular port?
Is there any limit on the socket buffer size (maximum data can be send at a time through wsk socket)?

Is there any working example of winsock kernel other than the Winddk echo server?

Any thoughts would be highly appreciable.

Thanks & Regards,
AK

Are you properly closing the connection on both sides? Sounds like you
are running out of handles. Note that HTTP will open and close
connections as you describe and does not suffer from the problem you are
seeing, because otherwise most Web servers would quickly become catatonic.

Note that the idea of moving the socket handling into the kernel does not
seem to be relevant to solving this problem.

I would suggest looking at the number of open handles on the server side;
you are most likely failing to close a connection handle after it has
disconnected.
joe

We have a kernel driver with wsk connection socket running on one pc and
another kernel driver with wsk Listener socket running on another pc.
We have configured the socket buffer to 32KB and sending/receiving the
data with some 500ms delay between each send/receive.
We are opening and closing the socket for every send/receive.
It is observed that after some 20-30 mins the connections is getting break
and the Listener socket (server) becomes unresponsive.

Is there any limit on the number of open/close socket on a particular
port?
Is there any limit on the socket buffer size (maximum data can be send at
a time through wsk socket)?

Is there any working example of winsock kernel other than the Winddk echo
server?

Any thoughts would be highly appreciable.

Thanks & Regards,
AK


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

Note also that TCP/IP is a STREAM protocol. Your sender might send 32K;
there is not only no guarantee that your Receive call will deliver 32K,
but it is also specified that Recive is pretty much NOT guarantted to
return 32K. If you see that you send a 32K packet and your receiver
receives a 32K packet, THIS IS AN ACCIDENT, and once you start putting
routers in the middle, your code is going to fall apart. Trust me, I’ve
seen this mistake done over and over in app space, and it always seems to
come as a surprise to the programmer that TCP/IP is not a packet protocol.

Note that putting an incorrect implementation of an app in the kernel will
not make your code work correctly.
joe

Are you properly closing the connection on both sides? Sounds like you
are running out of handles. Note that HTTP will open and close
connections as you describe and does not suffer from the problem you are
seeing, because otherwise most Web servers would quickly become catatonic.

Note that the idea of moving the socket handling into the kernel does not
seem to be relevant to solving this problem.

I would suggest looking at the number of open handles on the server side;
you are most likely failing to close a connection handle after it has
disconnected.
joe

> We have a kernel driver with wsk connection socket running on one pc and
> another kernel driver with wsk Listener socket running on another pc.
> We have configured the socket buffer to 32KB and sending/receiving the
> data with some 500ms delay between each send/receive.
> We are opening and closing the socket for every send/receive.
> It is observed that after some 20-30 mins the connections is getting
> break
> and the Listener socket (server) becomes unresponsive.
>
> Is there any limit on the number of open/close socket on a particular
> port?
> Is there any limit on the socket buffer size (maximum data can be send
> at
> a time through wsk socket)?
>
>
> Is there any working example of winsock kernel other than the Winddk
> echo
> server?
>
> Any thoughts would be highly appreciable.
>
>
> Thanks & Regards,
> AK
>
> —
> 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
>


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

Thanks Joe, for the quick response.

As I have indicated in my previous mail. I am working on a kernel mode driver which can send/receive data from another kernel driver running on another pc.

This is a new stuff we are developing not that we are moving from application sockets to kernel sockets.

The problem is there are very less information available on net related to WSK. MSDN does have some useful information. Sometimes we may not find the specific data what we are looking for.
It would be really good if we can see some good example of WSK implementation.

Thanks,
Abraham

xxxxx@gmail.com wrote:

As I have indicated in my previous mail. I am working on a kernel mode driver which can send/receive data from another kernel driver running on another pc.

That may be the design you have chosen, but that does not mean it is the
RIGHT design. NEVER put any functions into kernel mode that can be
handled in user mode. The tools are better, the cost of a failure is
much smaller, the performance is the same, and the opportunities for
malware exploit vectors are much much lower.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.

> NEVER put any functions into kernel mode that can be handled in user mode.

You are truly a comedian, Tim…

The statement in itself is perfectly reasonable - in fact, this is one of the cornerstones of the UNIX philosophy.
However, when you say it in context of Windows programming…well, I don’t know about other people, but to me it sounds like telling a guy who lost millions on the stock market that he had dropped a dime…

Anton Bassov

It seems like a collosal waste of time. The only reason for doing this
seems to be that in user mode the server goes catatonic after some amount
of time. Instead of the onvious analysis (“I have a bug in my code”) the
immediate solution that comes to mind is “I can fix this by writing a
server in the kernel”, which seems to be one of the more remarkably silly
solutions one can invent. I suggested checking for handle exhaustion
caused by failure to close sockets, but there was no report I’ve seen that
suggests there was any attempt to examine handle usage. For that matter,
there is no suggestion that the consumption of thread handles is managed
properly. There is no hint that synchronous or asynchronous sockets are
used. There are a HUGE set of potential failure modes that were not
explored, or, apparently, even cosidered, but the “obvious” solution is to
implement the server in the kernel. This, to me, demostrates a serious
defect in how to analyze and solve problems. I think the best advice is
to say “good luck in your endevour” and lock this thread, because there
seems to be no way to convince them that the correct solution is to look
for and fix the bugs in their application.

I have seen several apps that exhibited similar pathologies, and the FIRST
thing to consider is handle leaks. The SECOND thing to consider is other
resource leaks. And, under NO circumstances, consider building it into
the kernel!

This is still at the level of “When I compile my program I get an error
that says the compiler has experienced an internal error” and expecting
Microsoft to respond by building the C++ compiler into the kernel.
joe

xxxxx@gmail.com wrote:
> As I have indicated in my previous mail. I am working on a kernel mode
> driver which can send/receive data from another kernel driver running on
> another pc.

That may be the design you have chosen, but that does not mean it is the
RIGHT design. NEVER put any functions into kernel mode that can be
handled in user mode. The tools are better, the cost of a failure is
much smaller, the performance is the same, and the opportunities for
malware exploit vectors are much much lower.


Tim Roberts, xxxxx@probo.com
Providenza & Boekelheide, Inc.


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

If the data that needs to be sent via a socket is generated by a driver in the kernel, should the driver team up with a user-mode server by inverted IRP and have the service do the sockets?

What I have been reading in this thread I have summarized as “There’s a
bug in my app, and my solution is not to expend any effort identifying the
bug, but instead, biulding the server into the kernel.”

If I am wrong in this interpretation, I still cannot come upwith a reason
thatbuilding a server into the kernel makes sense. There has not yet been
any coherent specification as to why it could possibly make sense to build
this into the kernel.

And, as you observe, if the goal is to send some kind of data created in
the kernel, then inverted call would indeed be the correct solution.

It is worth noting that if you do some arithmetic, such as dividing the
time to failure by 16,000 and believe the number that the clients access
the server every 500ms, you get a number that looks very suspiciously
credible for unclosed socket and/or thread handles.

Since we have seen no example of the application source code, it is not
clear that the threads are being created or terminated correctly.
Amateurs make a fairly consisten set of errors. And anyone who decides
the server should run in the kernel simply does not have the experience to
be considered other than an amateur.

Hint to OP: Check out my essays on UI threads, network programming, and
the n errors of defective Windows programs.
www.flounder.com/mvp_tips.htm. And just stop trying to write a network
server in the kernel. It only serves to frustrate you and annoy your
manager.
joe

If the data that needs to be sent via a socket is generated by a driver in
the kernel, should the driver team up with a user-mode server by inverted
IRP and have the service do the sockets?


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

First question I would ask is why MS provided the interface??? Is it to
show off that what can be done - but don’t do it???

When it first came out, I looked at it. Isn’t is in vista time frame? I
even wrote a blog about trying some simple client and server, the reason
was that in the past there was only few software package based on TDI, and
this new interface was very welcoming!!!

In case, someone wants to look at what I just said, go look at
prokash.squarespace.com and hunt down that article. Not particulary a very
thorough one, but it is a blog, and only initiated ones will be able to
follow it…

-pro

On Wed, Jun 26, 2013 at 6:43 PM, wrote:

> What I have been reading in this thread I have summarized as “There’s a
> bug in my app, and my solution is not to expend any effort identifying the
> bug, but instead, biulding the server into the kernel.”
>
> If I am wrong in this interpretation, I still cannot come upwith a reason
> thatbuilding a server into the kernel makes sense. There has not yet been
> any coherent specification as to why it could possibly make sense to build
> this into the kernel.
>
> And, as you observe, if the goal is to send some kind of data created in
> the kernel, then inverted call would indeed be the correct solution.
>
> It is worth noting that if you do some arithmetic, such as dividing the
> time to failure by 16,000 and believe the number that the clients access
> the server every 500ms, you get a number that looks very suspiciously
> credible for unclosed socket and/or thread handles.
>
> Since we have seen no example of the application source code, it is not
> clear that the threads are being created or terminated correctly.
> Amateurs make a fairly consisten set of errors. And anyone who decides
> the server should run in the kernel simply does not have the experience to
> be considered other than an amateur.
>
> Hint to OP: Check out my essays on UI threads, network programming, and
> the n errors of defective Windows programs.
> www.flounder.com/mvp_tips.htm. And just stop trying to write a network
> server in the kernel. It only serves to frustrate you and annoy your
> manager.
> joe
>
> > If the data that needs to be sent via a socket is generated by a driver
> in
> > the kernel, should the driver team up with a user-mode server by inverted
> > IRP and have the service do the sockets?
> >
> > —
> > 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
> >
>
>
>
> —
> 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
>

There is an old piece of folk wisdom I just made up: when you are standing
on thin ice, it is not a good idea to practice your skill with a jumprope.

What we have, as I have read the posts, is a failure to write a bug-free
application, so the solution is to write the same application in the
kernel.

And there is another old adage: don’t pursue gratuitous complexity when
simplicity is available. Otherwise known as KISS. The correct solution
is to fix the application. The idea that someone who can’t write a
bug-free application writing the same application as a kernel component is
terrifying.

There has been no response to my suggestion of poor handle management as
the source of the problem, and no response to the request about how
threads are launched and terminated.

The interface is probably available in the kernel to support reasonably
obscure situations for which a kernel-based solution makes sense. All
I’ve seen described in this thread is a buggy app that occasionally fails,
but instead of asking how to fix the bug, the question of how to write the
server in the kernel is posed as a solution. No other rationale was
given. So I put on my “manager’s hat” and say “WTF???”. If I were
managing this project, I would have killed this idea within 30 seconds of
hearing it. For the specified problem domain, I see nothing that requires
socket connections managed in the kernel. I do see a questioner who does
not appear to understand how to debug an application, and quite possibly
doesn’t understand network programming, making an ill-considered decision
to create a frankendriver that will create an unnatural network interface.
The number of times I’ve had to debug network apps written badly, written
by people who have no idea how to do correct socket or thread programming,
is probably in the dozens. In the old MFC group, we got questions like
this nearly every week. Nobody ever suggested building a kernel driver
that was a multithreaded network server as a solution to an erroneous app
or a bad design.
joe

First question I would ask is why MS provided the interface??? Is it to
show off that what can be done - but don’t do it???

When it first came out, I looked at it. Isn’t is in vista time frame? I
even wrote a blog about trying some simple client and server, the reason
was that in the past there was only few software package based on TDI, and
this new interface was very welcoming!!!

In case, someone wants to look at what I just said, go look at
prokash.squarespace.com and hunt down that article. Not particulary a very
thorough one, but it is a blog, and only initiated ones will be able to
follow it…

-pro

On Wed, Jun 26, 2013 at 6:43 PM, wrote:
>
>> What I have been reading in this thread I have summarized as “There’s a
>> bug in my app, and my solution is not to expend any effort identifying
>> the
>> bug, but instead, biulding the server into the kernel.”
>>
>> If I am wrong in this interpretation, I still cannot come upwith a
>> reason
>> thatbuilding a server into the kernel makes sense. There has not yet
>> been
>> any coherent specification as to why it could possibly make sense to
>> build
>> this into the kernel.
>>
>> And, as you observe, if the goal is to send some kind of data created in
>> the kernel, then inverted call would indeed be the correct solution.
>>
>> It is worth noting that if you do some arithmetic, such as dividing the
>> time to failure by 16,000 and believe the number that the clients access
>> the server every 500ms, you get a number that looks very suspiciously
>> credible for unclosed socket and/or thread handles.
>>
>> Since we have seen no example of the application source code, it is not
>> clear that the threads are being created or terminated correctly.
>> Amateurs make a fairly consisten set of errors. And anyone who decides
>> the server should run in the kernel simply does not have the experience
>> to
>> be considered other than an amateur.
>>
>> Hint to OP: Check out my essays on UI threads, network programming, and
>> the n errors of defective Windows programs.
>> www.flounder.com/mvp_tips.htm. And just stop trying to write a network
>> server in the kernel. It only serves to frustrate you and annoy your
>> manager.
>> joe
>>
>> > If the data that needs to be sent via a socket is generated by a
>> driver
>> in
>> > the kernel, should the driver team up with a user-mode server by
>> inverted
>> > IRP and have the service do the sockets?
>> >
>> > —
>> > 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
>> >
>>
>>
>>
>> —
>> 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
>>
>
> —
> 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

Who cares what their manager is thinking???

This is what he said earlier, just a couple email before on this thread…

Did you read it?

-pro

<>
Thanks Joe, for the quick response.

As I have indicated in my previous mail. I am working on a kernel mode driver which can send/receive data from another kernel driver running on another pc.

This is a new stuff we are developing not that we are moving from application sockets to kernel sockets.

The problem is there are very less information available on net related to WSK. MSDN does have some useful information. Sometimes we may not find the specific data what we are looking for.
It would be really good if we can see some good example of WSK implementation.

Thanks,
Abraham<>

Date: Wed, 26 Jun 2013 23:58:15 -0400
Subject: Re: [ntdev] Winsock Kernel (WSK) support
From: xxxxx@flounder.com
To: xxxxx@lists.osr.com

There is an old piece of folk wisdom I just made up: when you are standing
on thin ice, it is not a good idea to practice your skill with a jumprope.

What we have, as I have read the posts, is a failure to write a bug-free
application, so the solution is to write the same application in the
kernel.

And there is another old adage: don’t pursue gratuitous complexity when
simplicity is available. Otherwise known as KISS. The correct solution
is to fix the application. The idea that someone who can’t write a
bug-free application writing the same application as a kernel component is
terrifying.

There has been no response to my suggestion of poor handle management as
the source of the problem, and no response to the request about how
threads are launched and terminated.

The interface is probably available in the kernel to support reasonably
obscure situations for which a kernel-based solution makes sense. All
I’ve seen described in this thread is a buggy app that occasionally fails,
but instead of asking how to fix the bug, the question of how to write the
server in the kernel is posed as a solution. No other rationale was
given. So I put on my “manager’s hat” and say “WTF???”. If I were
managing this project, I would have killed this idea within 30 seconds of
hearing it. For the specified problem domain, I see nothing that requires
socket connections managed in the kernel. I do see a questioner who does
not appear to understand how to debug an application, and quite possibly
doesn’t understand network programming, making an ill-considered decision
to create a frankendriver that will create an unnatural network interface.
The number of times I’ve had to debug network apps written badly, written
by people who have no idea how to do correct socket or thread programming,
is probably in the dozens. In the old MFC group, we got questions like
this nearly every week. Nobody ever suggested building a kernel driver
that was a multithreaded network server as a solution to an erroneous app
or a bad design.
joe

> First question I would ask is why MS provided the interface??? Is it to
> show off that what can be done - but don’t do it???
>
> When it first came out, I looked at it. Isn’t is in vista time frame? I
> even wrote a blog about trying some simple client and server, the reason
> was that in the past there was only few software package based on TDI, and
> this new interface was very welcoming!!!
>
> In case, someone wants to look at what I just said, go look at
> prokash.squarespace.com and hunt down that article. Not particulary a very
> thorough one, but it is a blog, and only initiated ones will be able to
> follow it…
>
> -pro
>
>
> On Wed, Jun 26, 2013 at 6:43 PM, wrote:
> >
> >> What I have been reading in this thread I have summarized as “There’s a
> >> bug in my app, and my solution is not to expend any effort identifying
> >> the
> >> bug, but instead, biulding the server into the kernel.”
> >>
> >> If I am wrong in this interpretation, I still cannot come upwith a
> >> reason
> >> thatbuilding a server into the kernel makes sense. There has not yet
> >> been
> >> any coherent specification as to why it could possibly make sense to
> >> build
> >> this into the kernel.
> >>
> >> And, as you observe, if the goal is to send some kind of data created in
> >> the kernel, then inverted call would indeed be the correct solution.
> >>
> >> It is worth noting that if you do some arithmetic, such as dividing the
> >> time to failure by 16,000 and believe the number that the clients access
> >> the server every 500ms, you get a number that looks very suspiciously
> >> credible for unclosed socket and/or thread handles.
> >>
> >> Since we have seen no example of the application source code, it is not
> >> clear that the threads are being created or terminated correctly.
> >> Amateurs make a fairly consisten set of errors. And anyone who decides
> >> the server should run in the kernel simply does not have the experience
> >> to
> >> be considered other than an amateur.
> >>
> >> Hint to OP: Check out my essays on UI threads, network programming, and
> >> the n errors of defective Windows programs.
> >> www.flounder.com/mvp_tips.htm. And just stop trying to write a network
> >> server in the kernel. It only serves to frustrate you and annoy your
> >> manager.
> >> joe
> >>
> >> > If the data that needs to be sent via a socket is generated by a
> >> driver
> >> in
> >> > the kernel, should the driver team up with a user-mode server by
> >> inverted
> >> > IRP and have the service do the sockets?
> >> >
> >> > —
> >> > 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
> >> >
> >>
> >>
> >>
> >> —
> >> 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
> >>
> >
> > —
> > 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
>
>
>
> —
> 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

I can see doing some kind of redirector protocol, which might be one
reason the wsk interface could make sense.

I have found that if you don’t care what your manager is thinking, then
either your manager is not competent to manage, and/or you will be
blindsided at your next performance review.

I have had to deal with this in my role as a member of the technical
staff, who had an incompetent manger; in my role as middle manager when I
discovered te project managers weren’t caring what their team members were
doing, and as a consultant, in my role in dealing with managers. I found
that managers who don’t care often have managers above them who do. As a
consultant, I have often ended up in the VP’s office, explaining why the
manager who didn’t care has boxed the project into an unrecoverable corner
from which there is no way to save it short of a total rewrite.

If there’s one thing I learned over the 50 years of my career, is that
there is no faster way to disaster than by having a manager who doesn’t
care. And I can tell you that, before I fully internalized this, I was a
victim of bad management. That’s why I’m so sensitive to the issue. As a
consultant, I went to a lot of effort to lay a paper trail (virtual paper
trail) of emails in which design issues were discussed, and ideally
resolved. As an expert witness, I had to testify that, based on the paper
trail, that the firm (on whose behalf) had raised critical issues which
the client had chosen to ignore or had specifically told the company to
either ignore, or to do exactly the opposite, and sent requests a year
into the project that kept morphing the original spec out of recognition.
(The side I was testifying for, the firm that was contracted to build a
software artifact, won. But the core failure was the management liaison
was incompetent to manage).

Who cares what their manager is thinking???

This is what he said earlier, just a couple email before on this thread…

Did you read it?

-pro

<>
Thanks Joe, for the quick response.

As I have indicated in my previous mail. I am working on a kernel mode
driver which can send/receive data from another kernel driver running on
another pc.

This is a new stuff we are developing not that we are moving from
application sockets to kernel sockets.

The problem is there are very less information available on net related
to WSK. MSDN does have some useful information. Sometimes we may not find
the specific data what we are looking for.
It would be really good if we can see some good example of WSK
implementation.

Thanks,
Abraham<>

> Date: Wed, 26 Jun 2013 23:58:15 -0400
> Subject: Re: [ntdev] Winsock Kernel (WSK) support
> From: xxxxx@flounder.com
> To: xxxxx@lists.osr.com
>
> There is an old piece of folk wisdom I just made up: when you are
> standing
> on thin ice, it is not a good idea to practice your skill with a
> jumprope.
>
> What we have, as I have read the posts, is a failure to write a bug-free
> application, so the solution is to write the same application in the
> kernel.
>
> And there is another old adage: don’t pursue gratuitous complexity when
> simplicity is available. Otherwise known as KISS. The correct solution
> is to fix the application. The idea that someone who can’t write a
> bug-free application writing the same application as a kernel component
> is
> terrifying.
>
> There has been no response to my suggestion of poor handle management as
> the source of the problem, and no response to the request about how
> threads are launched and terminated.
>
> The interface is probably available in the kernel to support reasonably
> obscure situations for which a kernel-based solution makes sense. All
> I’ve seen described in this thread is a buggy app that occasionally
> fails,
> but instead of asking how to fix the bug, the question of how to write
> the
> server in the kernel is posed as a solution. No other rationale was
> given. So I put on my “manager’s hat” and say “WTF???”. If I were
> managing this project, I would have killed this idea within 30 seconds
> of
> hearing it. For the specified problem domain, I see nothing that
> requires
> socket connections managed in the kernel. I do see a questioner who
> does
> not appear to understand how to debug an application, and quite possibly
> doesn’t understand network programming, making an ill-considered
> decision
> to create a frankendriver that will create an unnatural network
> interface.
> The number of times I’ve had to debug network apps written badly,
> written
> by people who have no idea how to do correct socket or thread
> programming,
> is probably in the dozens. In the old MFC group, we got questions like
> this nearly every week. Nobody ever suggested building a kernel driver
> that was a multithreaded network server as a solution to an erroneous
> app
> or a bad design.
> joe
>
> > First question I would ask is why MS provided the interface??? Is it
> to
> > show off that what can be done - but don’t do it???
> >
> > When it first came out, I looked at it. Isn’t is in vista time frame?
> I
> > even wrote a blog about trying some simple client and server, the
> reason
> > was that in the past there was only few software package based on TDI,
> and
> > this new interface was very welcoming!!!
> >
> > In case, someone wants to look at what I just said, go look at
> > prokash.squarespace.com and hunt down that article. Not particulary a
> very
> > thorough one, but it is a blog, and only initiated ones will be able
> to
> > follow it…
> >
> > -pro
> >
> >
> > On Wed, Jun 26, 2013 at 6:43 PM, wrote:
>> >
>> >> What I have been reading in this thread I have summarized as “There’s
>> a
>> >> bug in my app, and my solution is not to expend any effort
>> identifying
>> >> the
>> >> bug, but instead, biulding the server into the kernel.”
>> >>
>> >> If I am wrong in this interpretation, I still cannot come upwith a
>> >> reason
>> >> thatbuilding a server into the kernel makes sense. There has not yet
>> >> been
>> >> any coherent specification as to why it could possibly make sense to
>> >> build
>> >> this into the kernel.
>> >>
>> >> And, as you observe, if the goal is to send some kind of data created
>> in
>> >> the kernel, then inverted call would indeed be the correct solution.
>> >>
>> >> It is worth noting that if you do some arithmetic, such as dividing
>> the
>> >> time to failure by 16,000 and believe the number that the clients
>> access
>> >> the server every 500ms, you get a number that looks very suspiciously
>> >> credible for unclosed socket and/or thread handles.
>> >>
>> >> Since we have seen no example of the application source code, it is
>> not
>> >> clear that the threads are being created or terminated correctly.
>> >> Amateurs make a fairly consisten set of errors. And anyone who
>> decides
>> >> the server should run in the kernel simply does not have the
>> experience
>> >> to
>> >> be considered other than an amateur.
>> >>
>> >> Hint to OP: Check out my essays on UI threads, network programming,
>> and
>> >> the n errors of defective Windows programs.
>> >> www.flounder.com/mvp_tips.htm. And just stop trying to write a
>> network
>> >> server in the kernel. It only serves to frustrate you and annoy your
>> >> manager.
>> >> joe
>> >>
>> >> > If the data that needs to be sent via a socket is generated by a
>> >> driver
>> >> in
>> >> > the kernel, should the driver team up with a user-mode server by
>> >> inverted
>> >> > IRP and have the service do the sockets?
>> >> >
>> >> > —
>> >> > 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
>> >> >
>> >>
>> >>
>> >>
>> >> —
>> >> 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
>> >>
>> >
>> > —
>> > 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
>>
>>
>>
>> —
>> 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
>
> —
> 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

All said and done - I understand!

One thing is hard for me to understand the context/intent/plan for other project that I never seen.

So I said “Who cares …”

Yes, pls internalize, and take good care of yourself!. You just came out of hospital!

-pro

Date: Thu, 27 Jun 2013 04:16:07 -0400
Subject: RE: [ntdev] Winsock Kernel (WSK) support
From: xxxxx@flounder.com
To: xxxxx@lists.osr.com

I can see doing some kind of redirector protocol, which might be one
reason the wsk interface could make sense.

I have found that if you don’t care what your manager is thinking, then
either your manager is not competent to manage, and/or you will be
blindsided at your next performance review.

I have had to deal with this in my role as a member of the technical
staff, who had an incompetent manger; in my role as middle manager when I
discovered te project managers weren’t caring what their team members were
doing, and as a consultant, in my role in dealing with managers. I found
that managers who don’t care often have managers above them who do. As a
consultant, I have often ended up in the VP’s office, explaining why the
manager who didn’t care has boxed the project into an unrecoverable corner
from which there is no way to save it short of a total rewrite.

If there’s one thing I learned over the 50 years of my career, is that
there is no faster way to disaster than by having a manager who doesn’t
care. And I can tell you that, before I fully internalized this, I was a
victim of bad management. That’s why I’m so sensitive to the issue. As a
consultant, I went to a lot of effort to lay a paper trail (virtual paper
trail) of emails in which design issues were discussed, and ideally
resolved. As an expert witness, I had to testify that, based on the paper
trail, that the firm (on whose behalf) had raised critical issues which
the client had chosen to ignore or had specifically told the company to
either ignore, or to do exactly the opposite, and sent requests a year
into the project that kept morphing the original spec out of recognition.
(The side I was testifying for, the firm that was contracted to build a
software artifact, won. But the core failure was the management liaison
was incompetent to manage).
>
>
>
>
> Who cares what their manager is thinking???
>
>
> This is what he said earlier, just a couple email before on this thread…
>
>
> Did you read it?
>
>
> -pro
>
>
> <>
> Thanks Joe, for the quick response.
>
>
> As I have indicated in my previous mail. I am working on a kernel mode
> driver which can send/receive data from another kernel driver running on
> another pc.
>
> This is a new stuff we are developing not that we are moving from
> application sockets to kernel sockets.
>
> The problem is there are very less information available on net related
> to WSK. MSDN does have some useful information. Sometimes we may not find
> the specific data what we are looking for.
> It would be really good if we can see some good example of WSK
> implementation.
>
> Thanks,
> Abraham<>
>
>
>
>
>> Date: Wed, 26 Jun 2013 23:58:15 -0400
>> Subject: Re: [ntdev] Winsock Kernel (WSK) support
>> From: xxxxx@flounder.com
>> To: xxxxx@lists.osr.com
>>
>> There is an old piece of folk wisdom I just made up: when you are
>> standing
>> on thin ice, it is not a good idea to practice your skill with a
>> jumprope.
>>
>> What we have, as I have read the posts, is a failure to write a bug-free
>> application, so the solution is to write the same application in the
>> kernel.
>>
>> And there is another old adage: don’t pursue gratuitous complexity when
>> simplicity is available. Otherwise known as KISS. The correct solution
>> is to fix the application. The idea that someone who can’t write a
>> bug-free application writing the same application as a kernel component
>> is
>> terrifying.
>>
>> There has been no response to my suggestion of poor handle management as
>> the source of the problem, and no response to the request about how
>> threads are launched and terminated.
>>
>> The interface is probably available in the kernel to support reasonably
>> obscure situations for which a kernel-based solution makes sense. All
>> I’ve seen described in this thread is a buggy app that occasionally
>> fails,
>> but instead of asking how to fix the bug, the question of how to write
>> the
>> server in the kernel is posed as a solution. No other rationale was
>> given. So I put on my “manager’s hat” and say “WTF???”. If I were
>> managing this project, I would have killed this idea within 30 seconds
>> of
>> hearing it. For the specified problem domain, I see nothing that
>> requires
>> socket connections managed in the kernel. I do see a questioner who
>> does
>> not appear to understand how to debug an application, and quite possibly
>> doesn’t understand network programming, making an ill-considered
>> decision
>> to create a frankendriver that will create an unnatural network
>> interface.
>> The number of times I’ve had to debug network apps written badly,
>> written
>> by people who have no idea how to do correct socket or thread
>> programming,
>> is probably in the dozens. In the old MFC group, we got questions like
>> this nearly every week. Nobody ever suggested building a kernel driver
>> that was a multithreaded network server as a solution to an erroneous
>> app
>> or a bad design.
>> joe
>>
>> > First question I would ask is why MS provided the interface??? Is it
>> to
>> > show off that what can be done - but don’t do it???
>> >
>> > When it first came out, I looked at it. Isn’t is in vista time frame?
>> I
>> > even wrote a blog about trying some simple client and server, the
>> reason
>> > was that in the past there was only few software package based on TDI,
>> and
>> > this new interface was very welcoming!!!
>> >
>> > In case, someone wants to look at what I just said, go look at
>> > prokash.squarespace.com and hunt down that article. Not particulary a
>> very
>> > thorough one, but it is a blog, and only initiated ones will be able
>> to
>> > follow it…
>> >
>> > -pro
>> >
>> >
>> > On Wed, Jun 26, 2013 at 6:43 PM, wrote:
> >> >
> >> >> What I have been reading in this thread I have summarized as “There’s
> >> a
> >> >> bug in my app, and my solution is not to expend any effort
> >> identifying
> >> >> the
> >> >> bug, but instead, biulding the server into the kernel.”
> >> >>
> >> >> If I am wrong in this interpretation, I still cannot come upwith a
> >> >> reason
> >> >> thatbuilding a server into the kernel makes sense. There has not yet
> >> >> been
> >> >> any coherent specification as to why it could possibly make sense to
> >> >> build
> >> >> this into the kernel.
> >> >>
> >> >> And, as you observe, if the goal is to send some kind of data created
> >> in
> >> >> the kernel, then inverted call would indeed be the correct solution.
> >> >>
> >> >> It is worth noting that if you do some arithmetic, such as dividing
> >> the
> >> >> time to failure by 16,000 and believe the number that the clients
> >> access
> >> >> the server every 500ms, you get a number that looks very suspiciously
> >> >> credible for unclosed socket and/or thread handles.
> >> >>
> >> >> Since we have seen no example of the application source code, it is
> >> not
> >> >> clear that the threads are being created or terminated correctly.
> >> >> Amateurs make a fairly consisten set of errors. And anyone who
> >> decides
> >> >> the server should run in the kernel simply does not have the
> >> experience
> >> >> to
> >> >> be considered other than an amateur.
> >> >>
> >> >> Hint to OP: Check out my essays on UI threads, network programming,
> >> and
> >> >> the n errors of defective Windows programs.
> >> >> www.flounder.com/mvp_tips.htm. And just stop trying to write a
> >> network
> >> >> server in the kernel. It only serves to frustrate you and annoy your
> >> >> manager.
> >> >> joe
> >> >>
> >> >> > If the data that needs to be sent via a socket is generated by a
> >> >> driver
> >> >> in
> >> >> > the kernel, should the driver team up with a user-mode server by
> >> >> inverted
> >> >> > IRP and have the service do the sockets?
> >> >> >
> >> >> > —
> >> >> > 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
> >> >> >
> >> >>
> >> >>
> >> >>
> >> >> —
> >> >> 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
> >> >>
> >> >
> >> > —
> >> > 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
> >>
> >>
> >>
> >> —
> >> 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
> >
> > —
> > 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
>
>
>
> —
> 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