Hi All,
Is there reliable kernel level socket programming example program, where server can listen for multiple clients(many) connection request and responses it and clients which can send different application request(expecting different data structure) to the server running with multiple thread simultaneously.
Thanks & Regards,
Shivaprakash
The only one I know of comes with the wdk.
Last I looked, it had some issues.
Good luck,
Mm
Sent from my Verizon Wireless 4G LTE DROID
xxxxx@gmail.com wrote:
Hi All,
Is there reliable kernel level socket programming example program,
where server can listen for multiple clients(many) connection request
and responses it and clients which can send different application
request(expecting different data structure) to the server running with
multiple thread simultaneously.
Thanks & Regards,
Shivaprakash
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
> Hi All,
Is there reliable kernel level socket programming example program, where
server can listen for multiple clients(many) connection request and
responses it and clients which can send different application
request(expecting different data structure) to the server running with
multiple thread simultaneously.Thanks & Regards,
Shivaprakash
It sounds as if you are trying to put a TCP/IP or UDP server in the
kernel. Why? What advantage does this have over what can already be done
at the app level with a multithreaded server? And, for that matter, what
is the advantage of a multithreaded server app (one thread per connection)
over a single-threaded asynch socket app? (there actually are several
valid reasons for doing this, but you have to be able to justify the
single/multiple thread choice; you don’t do it because it sounds cool; you
do it because there is a sound reason for doing so).
The nature of sockets is that they are owned by an app. You do not need
to have multiple apps connected to a single socket, using different
protocols for each app, and doing automatic routing based on the protocol.
You can do all of this at app level anyway. You can’t say “I don’t like
how sockets were defined, and I want to create my own definition of a
socket, which differs from the standard one because…” I don’t think it
matters much what you do after “because” because I think the idea is going
to result in something very messy both to write and to connect clients to.
I’ve done some pretty heavy-duty socket programming at app level.
Microsoft used to have a sample of a multithreaded server, and other than
the fact it got sockets wrong, communication wrong, multithreading wrong
and synchronization wrong, there was nothing wrong with it. I once saw a
$500,000 project sink to oblivion because the incompetent programmer
started out using synchronous sockets, then retrofitted asynch sockets
badly, and used the completely wrong Microsoft article to build a
mulithreaded server. It was so bad that the only way it could have been
salvaged would have been a total rewrite, for which they had no budget.
So the whole project was terminated.
It sounds like you are trying to create in the kernel a solution best done
with either asynch app sockets in a single thread, or a multithreaded
solution using asynch sockets. To me, this sounds about as sensible as
building a C++ compiler that runs in the kernel.
What problem do you think this is going to solve? It can’t be
performance, because the counterexample is that hundreds of thousands of
socket-level programs have been created, and many of them coexist with
other socket programs, and socket performance is not a significant issue.
Why do you want to multiplex multiple apps into a single socket, anyway,
when this runs completely counter to the fundamental design of how sockets
work.
Note that the idea that synchronous sockets are a really easy way to
writer servers, and asynch sockets are difficult, can come about only if
you don’t understand how to program with asynch sockets. And no, no sane
programmer ever programs at the raw socket level; it is too finicky. For
serious socket work, use the MFC CAsynchSocket class, or buy any of a
number of good-and-come-with-complete-source asynch socket libraries. I
use CAsynchSocket. CSocket, the synchronous class, actually has serious
bugs in it. One you fully internalize the asynchronous, message-driven
architecture for apps, asynch socket programming is trivial. If you are
wedded to synchronous socket I/O, you think it is because it is “easy”.
It isn’t. Not if you want to build robust and reliable servers. The
“ease of use” is an illusion that breaks down rather badly at the points
where you most need to deal with problems.
I would suggest not wasting time trying to re-invent a new kind of socket
programming (you have no idea how difficult this is going to be), and
stick with the current model, which works just fine. Note that anyone can
apply for a port assignment, there is no cost, and you can have it in
about a month. I “own” (on behalf of one of my clients) a port number.
Took me maybe five minutes to fill out the application for it and submit
it to IANA [Internet Assigned Number Authority]. I don’t see how building
a complex server in the kernel and making all the necessary changes to
make it work with apps produces a meaningful result.
joe
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/seminarsTo unsubscribe, visit the List Server section of OSR Online at
http://www.osronline.com/page.cfm?name=ListServer