I'm trying to write a windows kernel driver which requires tcp/ip communication using NDIS 5/6. Since it will use NDIS, as I understand it, it needs it's own tcp/ip stack implementation.
Could anyone point me in the direction of an implementation of this, or something close to it?
Any help would be greatly appreciated!
Kind regards
You don't need to implement your own TCP/IP stack!
First, are you sure that this needs to be done in a driver? All your complex code and business logic should usually be in a usermode application or service. Drivers are mostly meant to be very simple wrappers around hardware. This rule isn't just some abstract principle either — it's much easier to write usermode code, where you can use a familiar debugger and the much-broader set of Win32 APIs. You'll solve your problem sooner if you can move most of your code to usermode.
If you really must do TCP socket I/O in kernel mode, then you should use Winsock Kernel (WSK). WSK allows you to open a socket, similar to Winsock in usermode. (Although the usermode Winsock API has more options and features; WSK is bare-bones).
WSK is available on Windows Vista and later. If you must support Windows XP, then you need to use TDI. TDI is much harder to get right; I don't reccomend using it if you can avoid it.
Related
I've been asked to implement VPN capabilities in an existing software project on an embedded system, in order to make the device available via network to an external server while avoiding trouble with firewalls (no need for encryption, just to make it accessible).
Unfortunately, the embedded system is based on a Cortex-M4 MCU, therefore Linux, which would allow for VPN nearly out of the box, is not an option. All I've got is an RTOS and a working LwIP stack.
I've used VPNs in the past. However, my network knowledge is rather limited concerning implementing VPNs, so I'm rather stumped. As I think, I'd use the current LwIP instance for building up the tunnel connection, and the application would use a second instance for the actual network communication, while the network interface of the second instance is a virtual one (like a tap device on linux), encapsulating its low level data and tranceiving it via the tunnel connection of the first LwIP instance.
Maybe this way I'd be able to create a custom solution for the problem, but the solution should conform to any standards (as the server will be any kind of sophisticated system).
So I wonder if anyone has been confronted with a task like this, and would appreciate any hint what to do, at least a direction where to look at.
Thanks in advance!
Would a Tun/tap device avoid a netmap/pf_ring/dpdk installation ? If tun/tap allow to bypass kernel, isn't it the same thing ?
Or those codes bring so many optimizations that they overclass tun os bypass strategy ?
The final goal is to port tcp/ip from kernel to user space, FOR TESTING PURPOSES.
I don't quite understand here.
Thanks
no.
for userspace tcpip implementation see lwip or rumpkernel.
dpdk/pfring/netmap as you probably know are about getting packets to userspace as fast as possible.
tun/tap are virtual interface things. probably not what you're after.
Tun/tap are not particularly performant. They miss out on the IP stack, but there is a lot of copying still involved. Profile some code using them to see. I think the best option for straight userspace networking is probably AF_PACKET using the ring buffer option, but that will is still an indirect ring buffer that gets copied to the network card ring buffer rather than being direct like you get with solutions like dpdk. It depends on your performance requirements - if it is just for testing correctness any solution should be fine.
I've used netty with udp and tcp protocols.
To my surprise it can be used with serial port as well.
Transport used is rxtx, there are a very few positive recommendations for rxtx.
Can netty be used with jssc instead of rxtx?
Should an application developer really care about the underlying implementation (rxtx or jssc)?
Should there be a problem developing in x86 then swapping to ARM?
There is currently no support for jssc, but you could write your own transport implementation using it.
As Norman said you could write your own jssc channel implementation to make it work with netty. However you may find ready libraries here below:
Original lib:
https://github.com/jkschneider/netty-jssc
My fork with some fixes:
https://github.com/tttomat19/netty-jssc
Regarding ARM/x86 question I believe jssc supports ARM, but I did not try it.
Regarding rxtx and jssc comparison I had unpleasant experience with rxtx performance and maven build.
How (GA) Global array library (an implementation of ARMCI) is used for communication between two process located on different remote machines.
Is that something similar to TCP socket programming where one process wait for data and the other transfers it ?
I try to see the documentation that ga_put() and ga_get() are two operation that used for inter-process communication. till now I only able to come up with a program running on the same machine that use shared-Memory architecture (I have used ga_put() and ga_get() to put data in Global array and to get it respectively ).
Now, I want use this program for communicating data (basically performaning one-sided communication) between two remote processes. Obiviously putting the program that I am running on single machine on the remote side will work out. It needs some way to tell which machine should we access and get the right data. And here is where I need your help. how can I do this? (what is its equivalent of TCP/IP listen, accept and connect ... on GA ? )
Or is that the case that GA also uses TCP/IP socket underneath ?
can some one please explain to me? and sample code of two remote processes communicating is also appreciable.
thanks,
I am answering my question after all. May be it will help some one looking for the same issue.
GA Library is implemented to work with MPI. So we have something like:
MPI_Init(..)
GA_Initialize()
MA_Init(..)
// .... do sothing here
GA_Terminate()
MPI_Finalize()
The answer to my question is:
MPI has the following primitives to be able to support client-server commuication:
//in the server side
MPI_Open_port()
MPI_Comm_accept()
//do MPI_Send() or MPI_Recv()
MPI_Close_port()
//client Side
MPI_Comm_connect()
//do MPI_Recv() or MPI_Send()
depending on the hardware support and the MPI implementation used, MPI might use sockets, or other mechanisms (e.g SAN (System area network)).
In general, most MPI implementations use sockets for TCP based communication.
So, yes GA also uses sockets underneath (of course depending on the MPI implementation used)
cheers,
The question is pretty self-explanatory, I require the ability to open and control a socket from a kernel mode driver in windows xp. I know that vista and after provides a kernel mode winsock equivalent, but no such thing for XP.
Cheers
Edit
I've had a recommendation to have a user-mode service doing the socket work, and one to use TDI. Which is best?
TDI is not an easy interface to use. It is designed to abstract network transport drivers (TCP, NetBEUI, AppleTalk, etc) from applications. You will have to fully understand the API to be able to use it for socket work - this is certainly a lot more work than writing a user-mode service and communicating with that. You can issue a reverse IRP from the service to the driver, so the driver can trigger comms when it needs to.
Also, the more complexity you remove from your driver (here, into user-mode), the better.
However, using a user-mode service will require a context switch per data transfer to the driver, which for you might be on a per-packet basis. This is an overhead best avoided.
I'm curious as to why a driver needs to perform network I/O. This superficially at least seems to indicate a design issue.
Use TDI interface, it's avaliable on XP and Vista.
http://msdn.microsoft.com/en-us/library/ff565112.aspx