Thanks for the reply…Actually its been my mistake to over empasize the
user mode application. I am building the user mode application for testing
purposes only, just to see whether I am able to send and receive UDP
packets faster. In reality, my driver would be sending and receiving all
the audio video packets at a higher speed. So there comes the necessity of
building something in the kernel mode, which looks at every packet, not
just the packets for a particular user mode app.
Now another question. Given the above scenario, how do you think that I
can speed up reception of audio video data? One way which I thought was
reordering the receive buffer so that audio/video data gets transmitted up
faster and leave the other packets to be sent up later. But you seem to
say that this idea wont work. Why is this? Your idea of sending up the
special packet directly to the app is not my concern since it would not be
just one single app but any app which is looking forward to audio video
data. The user app that I would make is only for testing. I think you get
my point. Can you suggest some architecture for it?
Ok, about sending the packets, I think you agree to my IOCTL thing. So no
problem with that. Still, if you feel something better can be done, then
guide me.
As I said, I am still designing the architecture and would welcome any
idea regarding my problem. Please be kind enough to help.
Regards
Arijit.
On Tue, 2004-08-24 at 06:29, Arijit Bhattacharyya wrote:
> Well, I had to develop something in the kernel mode that would resort to
> high speed streaming . So I guess making an intermediate driver was one
> choice. Well, I am stll in the design phase, so if you think that there
> is
> some other design that would be more efficient and easier to make in the
> kernel mode,
I’m not sure it would be more efficent, but I’m guessing another design
could be “effecient enough” for your requirements. I vaguely remember
Arlie Davis posting something in this forum a long time ago about how to
optimize networking from user mode. He seemed to indicate that you
shouldn’t have any trouble, if you use winsock properly. What are your
performance requirements? What made you decide you had to write
kernel-mode code?
> I would be glad to hear it. Another thing which you did not
> mention was whether an IOCTL interface would be suffice. Can I send UDP
> packets down to the intermediate driver by transferring it into a user
> buffer? and similarly, when I receive a packet destined for that user
> app,
> then how should I handle that packet?.
Yeah, the basic idea would be that you would build your UDP datagram in
a user buffer, IOCTL that to the driver as METHOD_DIRECT, and then the
driver would directly forward it to the card. You’ll have to add a MAC
header in the IM driver, unless you ioctl the source mac. Also, you’ll
have to resolve the dest mac address with ARP from user mode (I think
the function for this is in iphlpapi).
As for inbound, you’d have to parse every packet that comes in and look
for your special packets. This is similar to any other packet filtering
code. Ioctl the right packets back to usermode and you’re done.
The details are a little tricky; study passthru and www.ndis.com.
> One idea is as follows:
>
> 1)set up a socket in the user app which is listening at a port
> 2)when a packet comes at the NIC destined for the specified port, then
> in
> the intermediate driver, just push that packet to the top of the receive
> buffer so that it is delivered faster to that particular port.
I’m not quite sure how this works; you’re not bypassing winsock at all
here, and you seem to be thinking you can reorder tcpip.sys’s internal
queues. I may be misunderstanding you, but if i’m not, this idea is
doomed. Either do normal winsock calls (recommended) or do the ioctl
thing I described above.
-sd
Questions? First check the Kernel Driver FAQ at
http://www.osronline.com/article.cfm?id=256
You are currently subscribed to ntdev as: xxxxx@fht-esslingen.de
To unsubscribe send a blank email to xxxxx@lists.osr.com