Conference 7.286::fddi

    Re: .0
    
    1. I don't know of any minimum length requirement.  I assume that if
       the link confidence test passes, then you have an OK connection.
       There are enough mechanical issues of connecting two nodes
       together that would negate any need to concern with cables being too
       short.
    
    2. We don't provide an API on Windows NT, but the Microsoft Windows NT
       DDK provides example driver and application code that communicates
       with hardware devices.
    
    /l

>>    2. Do we provide API on OpenVMS and Window NT?  They want to access the
>>    FDDI interface directly instead of sending data via IP or DECnet.  And
>>    does this FDDI API provide multicasting sending and receiving support
>>    similar to what is provided by Ethernet API?  Where can I get more
>>    information of the API?
                             
For VMS, there is the low performance option of QIO, described in the LAN
chapter of the I/O Users Guide.  For much better performance, there is the
VCI interface.  There is some publicly available documentation (I'll have to
look around to see where its located).

- Dick

VCI documentation is located as follows:

From:   STAR::GAGNE        "David Gagne, VMS Development, 381-1467" 28-APR-1994 15:34:18.30
To:     GAGNE
CC:
Subj:   Where's the LANVCI spec

It's on the VMS060 condist only; not the VMS061 condist.

The VMS 6.0 condist part number is AG-PXKUB-RE.

The file is:

  [DOCUMENTATION.V060.HARDCOPY]LAN_VCI_10.PS(TXT)

Thanks.

David

>>    2. We don't provide an API on Windows NT, but the Microsoft Windows NT
>>       DDK provides example driver and application code that communicates
>>       with hardware devices.

Forgive my lack of knowledge about NT.
A customer wants to use our FDDI adapter in order to send/receive video data.
He would like to receive directly the video buffers above the NT driver then
do some work with these video buffer and resend these buffers to a MATROX video
board.

Does this mean that they have to develop a NT kernel transport layer above our
FFDI driver (NDIS 3.0 interface ?) and above the MATROX NT driver (NDIS 3.0
interface) ?

The above seems to imply kernel programming. What do I need to do this
processing (modification of buffers then forwarding these buffers to the
MATROX cards) using user mode programming ?

Did you hear about some customers having develop their own transport layer
above the the FDDI card driver (I suppose that 99 % of the customers are using
a standard Transport protocol such as TCP/IP, UDP/IP or DECnet).

I thank you in advance.
Damien (who should read "Windows NT for dummies", yes I know... as soon as I
	have some time, I do it... :-)

Damien,

What your customer is proposing sounds interesting, but we don't have direct
experience here (within NPB adapter engineering) with that level of
programming.

Certainly your customer should be able to write an NDIS-compliant "dummy"
stack that binds to the adapter, sends/receives frames, and communicates with
the video driver (through whatever standard means that's done).  I believe the
Microsoft DDK includes sample code for interfacing to the NDIS layer.

>>Did you hear about some customers having develop their own transport layer
>>above the the FDDI card driver (I suppose that 99 % of the customers are using
>>a standard Transport protocol such as TCP/IP, UDP/IP or DECnet).

I haven't heard of any that are FDDI-specific, but there are 3rd party
companies that have written IPX stacks, LAT stacks, etc, that sit on top of
NDIS and can support any NDIS-supported network driver, including FDDI.  It
certainly can be done, just don't ask me how!  :-)

You may want to try the DECWET::NT-DEVELOPERS conference also.

- Larry

Larry,
	Thank you VERY much for your quick answer.
	Something is not very clear to me. What is inside the buffers that I can
	get above the NDIS NT layer.

	I would assume that your firmware/driver removes all the FDDI stuff
	from these buffers (protocol headers/trailers).

	Is this correct ?
	
	For example, if I write my own driver above the NDIS layer and I receive
	some data coming from a remote system using a UDP/IP/FDDI stack does
	this mean that my driver will receive buffers containing ONLY  UDP/IP
	Protocol Data Unit ?

	What I describe seems to be just trivial independance of networking
	layers. But being almost ignorant about FDDI protocols, I just want
	to be sure that if we implement our own "dummy" transport layer to
	convey video data, we can simply and efficently retrieve the Video
	part of the Protocol Data Unit. In this "dummy" transport layer should
	we take care about timers/retransmission or whatever is inherant to
	your underlying FDDI data link ?

I thank you in advance,
Regards,
Damien.

>>	Something is not very clear to me. What is inside the buffers that I can
>>	get above the NDIS NT layer.
>>
>>	I would assume that your firmware/driver removes all the FDDI stuff
>>	from these buffers (protocol headers/trailers).
>>
>>	Is this correct ?

No, that's incorrect.  The NDIS driver passes up a fully formed FDDI frame to
the NDIS layer.  I don't know whether the NDIS wrapper removes the frame header
before presenting it to the protocol stacks.  My suspicion is that it *doesn't*
based on my belief that NDIS-compliant protocol stacks *are* by definition
media aware.  Naturally, the same holds true for transmit, the driver receives
a fully formed FDDI frame and only has to send it out on the network.

>>	For example, if I write my own driver above the NDIS layer and I receive
>>	some data coming from a remote system using a UDP/IP/FDDI stack does
>>	this mean that my driver will receive buffers containing ONLY  UDP/IP
>>	Protocol Data Unit ?

That may be true.  Here you're not sitting on top of NDIS, but rather, you're
sitting on top of Microsoft's TCP/IP stack.  Naturally, the TCP/IP stack will
pass the data up without media headers and most likely without transport
headers.

>>	What I describe seems to be just trivial independance of networking
>>	layers. But being almost ignorant about FDDI protocols, I just want
>>	to be sure that if we implement our own "dummy" transport layer to
>>	convey video data, we can simply and efficently retrieve the Video
>>	part of the Protocol Data Unit.

Again, depending on where you sit, you'll get different information.  Please
don't get too hung up on the FDDI media header.  The NDIS API includes macros
for dealing with the headers and frankly, FDDI headers are not much more
complicated than Ethernet headers.  Worst case if you do decide to implement a
proprietary protocol stack, supporting FDDI will be the least of your concerns.

>>In this "dummy" transport layer should we take care about timers/retransmission
>>or whatever is inherant to your underlying FDDI data link ?

No.

- Larry