130 likes | 298 Views
Streams – Chapter 31. Jari Kellokoski 10.6.2005. Introduction. Streams provide a full-duplex connection between a process and a driver Driver in this context is not necessary a hardware driver
E N D
Streams – Chapter 31 Jari Kellokoski 10.6.2005
Introduction • Streams provide a full-duplex connection between a process and a driver • Driver in this context is not necessary a hardware driver • Stream head consists of the kernel routines that are invoked when the application makes a system call for a streams descriptor (e.g. read, putmsg, ioctl)
Overview • A process can dynamically add and remove intermediate processing modules between the stream head and the driver • Any number of modules can be pushed onto a stream • Pushing means that module is inserted below the stream head • Special type of pseudo-device driver is a multiplexor that is accepting data from multiple sources
Overview cont. Process Stream head module kernel driver
Message Types • Streams messages are categorized as: • high priority, priority band and normal • 256 different priority bands – between 0 and 255 • normal messages are with priority 0 • The priority of streams message is used for queuing and flow control • …however in real life 1 is high priority and 0 for normal data
Message Types cont. • From application’s point of view there are usually only three different types of messages • M_DATA, M_PROTO, M_PCPROTO • See message types generated by write and putmsg:
Functions • getmsg • int getmsg(int fd, struct strbuf *ctlptr, struct strbuf *dataprt, int *flagsp); • putmsg • int putmsg(int fd, const struct strbuf *ctlptr, const struct strbuf *dataprt, int flags); • Control and data portions of the message is described by: • struct strbuf {int maxlen; /* max size of buf */int len; /* actual amount of data in buf */char *buf; /* data */}; • One can send – control information, only data or both • if no control then ctlptr is null and the same goes with data • if only data then M_DATA message is generated otherwise either an M_PROTO or an M_PCPROTO is generated depending on flags • flags is 0 for normal message or RS_HIPRI for high-priority message
Functions cont. • The final argument to getmsg is a value-result argument • If argument is 0 then the first message on the stream is returned (can be normal or high-priority) • If value is RS_HIPRI then we wait for a high-priority message to arrive • In both cases the value stored in the ingeter pointed to by flagsp will be 0 or RS_HIPRI depending on the type of message returned • When we pass non-null ctlptr and dataptr values to getmsg • if no control information then ctlptr->len to –1 • if no data to return then dataptr->len to –1 • Return value of putmsg is simple 0 for ok and –1 on error • Return value of getmsg is 0 only if the entire message was returned to the caller • if control buffer too small – MORECTL • if data buffer too small – MOREDATA • if both too small – logical OR of these flags is returned
Functions – Streams SVR4 variant • int getpmsg(int fd, struct strbuf *ctlptr, struct strbuf *dataprot, int *band, int flagsp); • int putpmsg(int fd, const struct strbuf *cliptr, const struct strbuf *dataprt, int band, int flags); • Band argument must be 0-255 and if flags argument is MSG_BAND then message is generated in the specific priority band • Setting flags to MSG_BAND and band of 0 is equivalent to calling putmsg • If flags is MSG_HIPRI band must be 0 and high-priority message is generated • For getpmsg integer pointed to by flagsp for getpmsg can MSG_HIPRI, MSG_BAND or MSG_ANY • And then message that was read pointed by flagsp contains MSG_HIPRI (for high-priority message) or MSG_BAND (other message was read)
Transport Provider Interface (TPI) • TPI is the service interface into the transport layer form above • Both sockets and XTI use this interface in a STREAMS environment • TPI is a message-based interface • It defines message that are exchanged up and down a stream between the application and the transport layer • One is able to bypass both socket and XTI and use TPI directly • However don’t do it…
Summary • Streams provide a full-duplex connection between a process and a driver • A process can dynamically add and remove intermediate processing modules between the stream head and the driver • Any number of modules can be pushed onto a stream • Functions: • getmsg • int getmsg(int fd, struct strbuf *ctlptr, struct strbuf *dataprt, int *flagsp); • putmsg • int putmsg(int fd, const struct strbuf *ctlptr, const struct strbuf *dataprt, int flags); • Functions – Streams SVR4 variant: • Band argument must be 0-255 and if flags argument is MSG_BAND then message is generated in the specific priority band • Transport Provider Interface (TPI) • Both sockets and XTI use this interface in a STREAMS environment
Conformance Testing of TCP/IP Stack in a Mobile Phone – Anssi Niemi • Kertoo tarinan TCP/IP:n testaamisesta ANVL:n avulla (Automated Network Validation Library) • Miten testiympäristö tehtiin • Miten testaus tehtiin • Sopii jokseenkin hyvin UNIX Network Programming kirjan kaveriksi • Näkokulmana järjestelmällinen testaus
Conformance Testing of TCP/IP Stack in a Mobile Phone • Hyvää • Mitä TCP/IP tarkoittaa matkapuhelimessa ja matkapuhelinverkossa (GSM ja vähän WCDMA:ta) • Konformanssitestauksen esittely • Huonoa: • Ei juurikaan pureudu ongelmiin (TCP/IP yhteensopivuus (esim. IP options), toiminta ongelmatilanteissa)