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
Related
I'm working on application running on JBossEAP 6.4 in domain mode. I need to handle multiple (up to 1000) parallel TCP connections from server to different hardware devices.
Connections have to be opened at server side and will be keept up to 90 seconds. All connections uses the same port and protocol, but destination IP adresses are different..
I wonder if JCA adapter is suitable for this use case. Should I create special Activation specification for every single device or use something else than JCA resource adapter?
The question is a bit old, but JCA is a not-that-popular technology so some knowledge about it would be useful despite of the fact you might have been implemented all the things already.
Firstly, JCA is a spec for writing your connector, it's not a connector implementation itself. If you need your application to work with external TCP it's up to you to implement a connector.
Whether JCA is suitable for your particular needs depends solely on the nature of your "different hardware devices". Resource adapters has been designed to be used on per-service basis with possible connections pooling. I.e. all the connections this particular adapter would fire should have quite similar nature and be interchangeable. However, JCA adapters also have sensible advantages outside of this scope, especially in EJB environment. EJB imposes quite harsh restrictions upon your code: no locking, threads spawning, etc. It might be quite difficult to implement TCP I/O without all those things. Here comes JCA and it's threading freedom (MDBs are capable of providing EJB-friendly scope on their activation despite of an underlying thread source).
In conclusion: you should consider using JCA for TCP networking if you're working in EJB environment (or if you're going to do so in observable future). If you're using Spring-powered environment upon Java EE stack it may worth to omit such a complicated technology and stick to some pure Netty networking.
If you choose to proceed with JCA, consider inspecting the JCA SocketConnector I am currently maintaining. It's build upon Netty stack and it could be a good start for you. You can also use it as a source of ideas how to build your own implementation instead.
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!
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.
This might be a lame question for this site, but here goes.
Can drivers be portable? For instance, could one write a driver for the keyboard-backlight of a mac, and port it to another unix system, maybe Solaris?
or is driver portability a contradiction in terms?
any articles covering this topic would be much appreciated.
Device drivers need to serve two layers of abstraction which makes portability at least hard:
1) Of course the driver needs to be written for a specific device. Your understandable assumption is now that once I implemented a driver according to a proper device specification (data sheet, ...), why shouldn't it run on every computer that needs to access the device.
In comes point
2) Drivers are written to fit into a certain operating system. Each OS has its own means of
a) accessing devices, e.g., the functions for reading/writing I/O ports might be called differently or have different signatures. Furthermore
b), the ultimate goal of a driver is to make the device accessible to the user - be it through a file system interface or network sockets or the X input protocol. For these purposes each OS again comes with its own set of abstractions that the driver needs to fit into.
These are the reasons porting drivers is kind of hard. Nevertheless, there are approaches that try to achieve this, most of the time by wrapping the original driver with glue code that translates the expected driver/OS interface into the target interfaces.
NDISWrapper is a library that allows running Windows WiFi drivers on Linux,
Some guys from Karlsruhe proposed to use device-driver virtual machines,
Several OS frameworks I'm aware of use device-driver wrapper libraries to run Linux/BSD device drivers in their environments. See for instance Genode, L4Re, Minix3.
Yes, they can be.
Assuming a driver is written for the device specifications, the only thing that prevents the driver portability is the underlying operating systems as different operating systems have different architecture and different controls to call and load device drivers.
But there have been known implementations, wherein the underlying OS could be abstracted and a uniform platform could be provided. This can lead to driver portability.
In most modern operating systems like Linux and Windows, is network IO typically accomplished using DMA? This is concerning generic Ethernet controllers; I'm not asking about things that require special drivers (such as many wireless cards, at least in Linux). I imagine the answer is "yes," but I'm interested in any sources (esp. for the Linux kernel), as well as resources providing more general information. Thanks.
I don't know that there really is such a thing as a generic network interface controller, but the nearest thing I know of -- the NE2000 interface specification, implemented by a large number of cheap controllers -- appears to have at least some limited DMA support, and more sophisticated controllers are likely to include more sophisticated features.
The question should be a bit different:
Is typical network adapter have dma
controller on board ?
After finding answer on this question ( i guess in 99.9% it will be yes), you should ask about specific driver for each card. I assume that any decent driver will fully utilize hardware capabilities (i.e DMA support in our case), but question about OS is not relevant, since no OS can force the driver to implement DMA support. A high level OS like Windows and Linux provide a primitives to easier implementation of DMA, but implementing is responsibility of the driver.