- SAN sample code
- Posted by sudhir on October 21st, 2005
Please help me on SAN sample code if any one has it.
ALso if sample for protocol driver which can replace TCP/IP.
- Posted by Maxim S. Shatskih on October 21st, 2005
Why not use system-supplied TCP/IP? Avoiding it is justified in one case
only - if the hardware has its own TCP/IP processor.
Also - what is "SAN" for you? iSCSI? or what?
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
"sudhir" <flytosudhir@rediffmail.com> wrote in message
news:1129875882.468090.258830@z14g2000cwz.googlegr oups.com...
- Posted by sudhir on October 21st, 2005
SAN - System Area Network. With this driver I can use socket functions
at application layer and have my own protocol for Sat Comm
Applications.
For Sat Comm Applications, I want to replace TCP/IP protocol as it is
not recommended for that.
- Posted by Maxim S. Shatskih on October 21st, 2005
Do you have the hardware TCP/IP processor board?
If no - then forget "not recommended" and use the usual TCP/IP stack.
If yes - then write the usual generic driver for the board and the user-mode
DLL to access it. The user mode DLL can be written as WinSock provider for some
address family of your own (which will really use the TCP/IP addressing), and
registered on the machine.
IIRC this is what is called WinSock Direct. This gives you the socket interface
to your hardware TCP/IP processor.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
- Posted by KOOLER on October 23rd, 2005
1) SAN stands for STORAGE and not SYSTEM Area Network. I can bet most
of the people
stopped reading your message after this wrong assertation 
2) Even if you'd manage to write own NDIS protocol driver it would take
you years to make it
BSD sockets compatible at user level. Ask Max how long did it take them
to write BSD sockets
library for NT kernel. And it was for TCP/IP and not for own protocol.
Grab a copy of ReactOS, check DDK and try reading this and OSR ntdev
forum archives - it would
give you at least approximate view of how large is whole network stack
you'll have to totally rewrite
yourself.
NDIS miniport (I think it's your hardware so it would be probably you
who would write NDIS compatible
driver for it) - NDIS protocol (it would be you who would write it) -
AFD equivalent - User mode DLL
3) Give a try to NDISPROT from the DDK, it has been there for a long
time. Dog slow (extra memory
copies and no event-driven I/O) but it's a pure strigh forward
sekeleton for your future TCP replacement
driver.
4) Still not clear why do you need SAN file system for this (original
post from you). In any case it's 10+
man years so no single person would give you a SAMPLE of it. Try
licensing SFS from DataPlow. It would
be faster.
Regards,
Anton Kolomyeytsev
CEO, Rocket Division Software
www.rocketdivision.com
- Posted by KOOLER on October 23rd, 2005
Max,
everything is just in opposite to what you say
If network hardware has limited or no TCP acceleration at all it really
makes
sense to stick with own raw ethernet NDIS protocol driver (shame on NT
kernel group for not making it standard component of the OS like it's
in Linux!)
and put something like ATA-over-Ethernet at the top of it. Using "el
cheapo"
GbE hardware AoE is better value for money and eats less CPU cycles per
megabyte of transferred data then very complex iSCSI. Situation
changes however
when TCP/iSCSI get fully accelerated in hardware (Alacritech
manufatures such a NICs
and a lot of companies make hardware iSCSI HBAs).
Regards,
Anton Kolomyeytsev
CEO, Rocket Division Software
www.rocketdivision.com
- Posted by Maxim S. Shatskih on October 24th, 2005
Just expose TDI as the upper egde of the protocol and write the WinSock helper
DLL. The simplified version of the TCP/IP WinSock helper is in the DDK
samples - WSHSMPLE.
Several months - this is with debugging and testing.
It is the universal TDI client, but have 1 IP-specific file to handle
conversion of sockaddr_in to TA_ADDRESS.
No need in AFD equivalent. If the protocol exposes TDI upper edge - then
existing AFD and MSAFD.DLL will be able to operate it.
You can also expose the proprierary IOCTL upper edge and the user-mode WinSock
provider DLL which will talk to these IOCTLs - but this means you will need to
have things like SO_SNDBUF/RCVBUF/lingering close/listen backlog to be
implemented yourself.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
- Posted by Maxim S. Shatskih on October 24th, 2005
Yes, this is a major flaw of MS to not include the Network Monitor driver as a
part of the OS and document it. Also - they have NDISUIO as a part of the Wi-Fi
stack (a proxy which allows the user-mode WZC code to send wireless OIDs) - but
it is not documented except on WinCE! Too bad. Anyway NDISUIO is IIRC uncapable
of data traffic - it only does OIDs IIRC.
--
Maxim Shatskih, Windows DDK MVP
StorageCraft Corporation
maxim@storagecraft.com
http://www.storagecraft.com
