-
-
Notifications
You must be signed in to change notification settings - Fork 2k
[NETIO] NETIO.SYS driver: An in-kernel BSD-style networking API #7262
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
[NETIO] NETIO.SYS driver: An in-kernel BSD-style networking API #7262
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for your contribution!
Ok, some style-nitpicks indeed.
In general you can find our Coding-style document here: https://reactos.org/wiki/Coding_Style
I will do some suggestions, that you can simply apply first, but I will also mention some things, that you have to push yourself afterwards, because I cannot use the github suggestions-feature for suggestions of such wide-scrope: First and foremost a suggestion of wide-scope:
- we do indent with spaces, not with tabs. 4 spaces per indentation level. That part is mandatory.
Like I said: accept some of my manual suggestions first, before doing the 4-indent-push afterwards yourself.
|
I am done with giving the most important style-hints, each in at least one location for now. I will let you act on them now, and will re-review later, whether they will have been applied consistently. Others will review the functional aspects later as well. |
|
Hi Joachim & others, Thank you for the review, I really should have read the CodingStyle first. Will push tomorrow Best regards,
|
Either works as our merging pull request procedure most of the time is squashing commits related to the pull request into a single one. You can both safely append new commits to your codebase and amend changes. |
As reviewed by Joachim Henze (reactos#7262) I used indent to fix most of the coding style issues: indent -o %2 -gnu -bli0 -hnl -nut -i4 -l110 -bls -ncs -npcs -nprs -nsaf -nsob -lp -cli4 -cbi0 %1
ad0dec2 to
eec2c28
Compare
|
Hi Timo, I just rebased the patch squeezing most of the commits. |
eec2c28 to
85488d6
Compare
|
Some suggestions for commit messages before merging: -TCPIP.SYS: Always depend on TCP/IP implementation for unspecified port (0).
+[TCPIP] Always depend on TCP/IP implementation for unspecified port (0)-[TDIHELPERS] Moved TDI helpers from AFD driver to separate directory
+[TDIHELPERS] Move TDI helpers from AFD driver to separate directory-[NETIO] NETIO.SYS driver
+[NETIO] Implement I/O driver for block devices over networkI also renamed PR title accordingly, if the responsible merger decides to use Squash & Merge strategy. |
In bind(2) when specifying 0 as port the TCP/IP (or also UDP/IP) driver is supposed to assign a free port number in the range 0xc000-0xffff. In the ReactOS TCP/IP driver there are two implementations of this mechanism: one in the "TCP/IP library" and one in the lwip TCP/IP stack. The TCP/IP library can reassign local ports to connection oriented sockets as soon as the address file (TDI) of a former connection oriented socket is closed. The problem that arises with such a port reuse is that the TCP/IP stack keeps the socket for a time period specified in the TCP/IP RFC (the state is called FINWAIT if I remember correctly). So if the same port is assigned twice we will get an status 0xc000020a (STATUS_ADDRESS_ALREADY_EXISTS) from the lwip implementation, thereby making new connections to the same remote IP/port pair with a newly created socket impossible. The solution I came up with (and which solves the can't connect any more issue) is to simply not use the TCPAllocatePort() mechanism when the port is 0 (unspecified) which lets the lwip implementation choose a free port (honoring sockets in FINWAIT state).
We want to use the TDI helper functions also in the NETIO.SYS driver which comes with the next commit. The code was modernized a bit (usage of DPRINT, doxygen style comments) but other than that it was left unchanged.
This patch adds the NETIO.SYS driver to ReactOS. NETIO.SYS is part of Windows since NT6 (Vista). The driver is not feature complete (meaning some functionality is unimplemented) but does its job quite good for what it originally was written for (which is getting WinDRBD working on ReactOS/Windows 2003 SP2). The driver re-uses parts of the AFD.SYS driver, namely those functions that ease communitating with the transport device interface (TDI). Other than that, following features are implemented and should work: * TCP/IP networking: connect, listen, accept, read, write * UDP/IP networking: write So in a nutshell TCP/IP support is completed, UDP support is partially complete and ICMP support does not exist yet. In particular the listen/accept mechanism allows one to write kernel side TCP servers that one can connect to via the internet.
85488d6 to
d7a04be
Compare
|
So I changed the commit messages and the pull request title to something more meaningful. |
Purpose
NETIO.SYS is a more convenient BSD style networking (TCP/IP, UDP/IP) kernel API
that is used by modern drivers (NDIS 6, WinDRBD). Originally
the intention was to have something to get networking with
WinDRBD working (http://github.com/johannesthoma/WinDRBD be sure to
pick the 1.2 branch, 1.1/stable will NOT work), a goal
that is already met by this version. Other features (like
UDP/IP receive from and the whole
RAW socket implementation) are still missing. What should work
is:
This is my first 'real' ReactOS project so please let me know
what you think. Especially coding style might not always match
the ReactOS style (I am used to Linux kernel style) so I am
asking for your understanding. Thanks a lot for reviewing this.
Best regards,
Proposed changes
Adding a new (NT 6) driver: NETIO.SYS
TODO
UDP/IP ReceiveFrom
Raw sockets
regression tests
and lots of other small stuff ...