> Dear Anthony
> Thanks for your reply.
> My STREAMS module is situated as follows:
> The application is calling libsocket.a and libnsl.a (socket, send, recv).
> It gets a SOCK_DGRAM socket and pushes my module on it.
> Thus my module sits above /dev/udp, just below the stream head.
> Cheers
> Tsay Mien
> > You might have to provide more information about what you are trying to
> > do. How does your driver interact with IP? Are you trying to send
> > packets out to network without going through IP? Or does your driver
> > sit above IP (like TCP or UDP) with you trying to send packets through
> > IP? Without knowing how your driver is suppossed to interact with the
> > rest of the system, it is difficult to tell what you need to do to get
> > it to work.
> > Tony
> > --
> > Anthony Collins Sr. Software Engineer
> > Network Associates, Inc.
Tsay,
OK, now I know how to answer your question. Unfortunately, as is
typical with the STREAMS environment, it is not a short answer. Both
TCP and UDP are transport providers (where transport corresponds to the
transport layer in the OSI reference model) and adhere to an interface
called the Transport Provider Interface (TPI). This is a standardized
set of STREAMS messages used by transport providers to provide services
to upper layers. The TPI interface is too involved for me to go into
all the details here. Fortunately, the TPI spec is available for free
online at http://www.opengroup.org/publications/catalog/c810.htm. You
have to register, but once you do, you can get at an HTML version of the
document.
You probably want to read the introduction and overview stuff just to
get a feel for how TPI works because, if you driver sits between
user-level and UDP, the messages that it deals with will all be TPI
messages. Fortunately, for a connectionless transport like UDP, there
are fewer messages than for a connection oriented transport like TCP.
Primarily, you will be interested in the T_UNITDATA_REQ messages which
hold datagrams coming from the user going to the transport provider and
T_UNITDATA_IND messages which hold datagrams coming from the transport
provider going to the user. The T_UNITDATA_REQ messages consist of an
M_PROTO message with a "struct T_unitdata_req" contained in it, and
linked M_DATA messages which hold the actual data. The T_unitdata_req
structure contains fields that point to where the actual protocol
address is stored in the M_PROTO message. You can find the definition
of the struct in the TPI spec and in the header file
/usr/include/sys/tihdr.h on a Sun box.
The protocol address itself is just a sockaddr_in struct. Thus, the
T_unitdata_req struct will just point to the sockaddr_in structure that
contains the IP address and UDP port. I assume from what you said below
that the user-level application is using sockets to communicate with the
network. Then, when the user issues the sendto (or send) call, the OS
automatically does the translation that converts the sockets based stuff
into the necessary TPI based STREAMS messages. This includes creating
the M_PROTO message and copying the destination address into it. So,
your driver doesn't have to know anything about sockets -- it just has
to understand how to deal with TPI STREAMS messages.
Sorry this is so long winded, but I hope it helps.
Tony
--
Anthony Collins Sr. Software Engineer
Network Associates, Inc.
by