SOCKET Driver Users Guide

Similar documents
Z/TPF TCP/IP SOCK Driver 12/14/10. z/tpf TCP/IP SOCKET Driver Users Guide. Copyright IBM Corp. 2010

Light & NOS. Dan Li Tsinghua University

TPF Communications - TCP/IP Enhancements

Contents. Part 1. Introduction and TCP/IP 1. Foreword Preface. xix. I ntroduction 31

Lecture 2. Outline. Layering and Protocols. Network Architecture. Layering and Protocols. Layering and Protocols. Chapter 1 - Foundation

Application Programming Interfaces

Socket Programming. CSIS0234A Computer and Communication Networks. Socket Programming in C

VALLIAMMAI ENGINEERING COLLEGE. SRM Nagar, Kattankulathur QUESTION BANK

TPF 4.1 Communications - TCP/IP Enhancements

SOCKET. Valerio Di Valerio

A set of processes distributed over a network that communicate via messages. Processes communicate via services offered by the operating system

NetCheck: Network Diagnoses from Blackbox Traces

LESSON PLAN. Sub. Code & Name : IT2351 & Network Programming and Management Unit : I Branch: IT Year : III Semester: VI.

CSE 461 Connections. David Wetherall

CptS 360 (System Programming) Unit 17: Network IPC (Sockets)

Programming with TCP/IP. Ram Dantu

Client Server Computing

How do we troubleshoot this? How does Esmeralda know how to fix this?

UNIX Network Programming

Socket Programming. Sungkyunkwan University. Hyunseung Choo Copyright Networking Laboratory

Computer Networks SYLLABUS CHAPTER - 2 : NETWORK LAYER CHAPTER - 3 : INTERNETWORKING

PROGRAMMING ASSIGNMENTS 3 & 4 TAO

A Client-Server Exchange

Sistemas Operativos /2016 Support Document N o 1. Files, Pipes, FIFOs, I/O Redirection, and Unix Sockets

CHETTINAD COLLEGE OF ENGINEERING AND TECHNOLOGY DEPARTMENT OF MCA QUESTION BANK UNIT 1

Connections. Topics. Focus. Presentation Session. Application. Data Link. Transport. Physical. Network

Presentation Services. Presentation Services: Motivation

CSEP 561 Connections. David Wetherall

CSEP 561 Connections. David Wetherall

Interprocess Communication

Operating Systems. 17. Sockets. Paul Krzyzanowski. Rutgers University. Spring /6/ Paul Krzyzanowski

JAVA SOCKET PROGRAMMING

Internet Connectivity with

Session NM056. Programming TCP/IP with Sockets. Geoff Bryant Process software

UNIX Sockets. Developed for the Azera Group By: Joseph D. Fournier B.Sc.E.E., M.Sc.E.E.

CSE 461 Module 11. Connections

Socket Programming for TCP and UDP

CSE 422 Jeopardy. Sockets TCP/UDP IP Routing Link $100 $200 $300 $400. Sockets - $100

Transport Layer (TCP/UDP)

We will cover in this order: 2.1, 2.7, 2.5, 2.4, 2.2

BITS-Pilani Hyderabad Campus

IPv4 and ipv6 INTEROPERABILITY

Network programming(ii) Lenuta Alboaie

Multicast. Note. Sending Multicast Messages

CS/ECpE 5516, Spring 1998, Midterm Exam 75 minutes, 120 points Prof. Abrams

Lecture 5 Overview! Last Lecture! This Lecture! Next Lecture! I/O multiplexing! Source: Chapter 6 of Stevens book!

Python Networking Chris Seddon

sottotitolo Socket Programming Milano, XX mese 20XX A.A. 2016/17 Federico Reghenzani

Distributed Systems 8. Remote Procedure Calls

ECE 650 Systems Programming & Engineering. Spring 2018

9th Slide Set Computer Networks

EEC-484/584 Computer Networks

(Refer Slide Time: 1:09)

What s an API? Do we need standardization?

Outline. Distributed Computer Systems. Socket Basics An end-point for a IP network connection. Ports. Sockets and the OS. Transport Layer.

ECE 650 Systems Programming & Engineering. Spring 2018

Memory-Mapped Files. generic interface: vaddr mmap(file descriptor,fileoffset,length) munmap(vaddr,length)

Network Implementation

Network Programming in Python. based on Chun, chapter 2; plus material on classes

z/tpf SSL Socket Driver User s Guide

CSE 461 The Transport Layer

Interprocess Communication Mechanisms

shared storage These mechanisms have already been covered. examples: shared virtual memory message based signals

Linux Kernel Application Interface

QUIZ: Longest Matching Prefix

COMMUNICATION PROTOCOLS: REMOTE PROCEDURE CALL (RPC)

Distributed Systems. How do regular procedure calls work in programming languages? Problems with sockets RPC. Regular procedure calls

Distributed Systems Recitation 2. Tamim Jabban

Tutorial on Socket Programming

The Fundamentals. Port Assignments. Common Protocols. Data Encapsulation. Protocol Communication. Tevfik Ko!ar

Socket Programming. Dr. -Ing. Abdalkarim Awad. Informatik 7 Rechnernetze und Kommunikationssysteme

Concurrent Architectures - Unix: Sockets, Select & Signals

Distributed Internet Applications - DIA. Servers and Sockets

Packet Sniffing and Spoofing

CSE/EE 461 Lecture 14. Connections. Last Time. This Time. We began on the Transport layer. Focus How do we send information reliably?

MPAC BENCHMARKING LIBRARY

TCP/IP Native Stack Roadmap for TPF 4.1

Server algorithms and their design

Sockets Sockets Communication domains

The Application Layer: Sockets Wrap-Up

UNIT IV- SOCKETS Part A

P2P Programming Assignment

Operating System Modifications for User-Oriented Addressing Model

Chapter 9: UDP sockets & address conversion function

Operating Systems. 18. Remote Procedure Calls. Paul Krzyzanowski. Rutgers University. Spring /20/ Paul Krzyzanowski

Ports under 1024 are often considered special, and usually require special OS privileges to use.

ELEC / COMP 177 Fall Some slides from Kurose and Ross, Computer Networking, 5 th Edition

Outline. Option Types. Socket Options SWE 545. Socket Options. Out-of-Band Data. Advanced Socket. Many socket options are Boolean flags

UNIX Sockets. COS 461 Precept 1

Vision Components. The Smart Camera People. VCRT 5.0 TCP/ IP Functions. TCP/ IP Operation System Functions

Operating Systems and Networks. Network Lecture 8: Transport Layer. Adrian Perrig Network Security Group ETH Zürich

Operating Systems and Networks. Network Lecture 8: Transport Layer. Where we are in the Course. Recall. Transport Layer Services.

EECS122 Communications Networks Socket Programming. Jörn Altmann

Network Programming. Introduction to Sockets. Dr. Thaier Hayajneh. Process Layer. Network Layer. Berkeley API

Introduction to Computer Systems. Networks 2. c Theodore Norvell. The Sockets API

CHAPTER 4: INTERPROCESS COMMUNICATION AND COORDINATION

Interprocess Communication. Interprocess Communication

Windows Socket Message-Driven/WSAAsyncSelect Model. Prof. Lin Weiguo Copyleft 2009~2015, College of Computing, CUC

Name: Mark Gambino Venue: SOA Subcommittee

Outline. Distributed Computing Systems. Socket Basics (1 of 2) Socket Basics (2 of 2) 3/28/2014

Transcription:

SOCKET Driver Users Guide File: Author: Owner: SOCK41.lwp official copy is on the Public Test Core Team Documents Lotus notes database Jamie Farmer Jamie Farmer Revisions: 1.

1.0 Introduction The socket driver consists of multiple DLMs that issue TCP/IP API calls to send and receive TCP data. There are many variations to the driver s functional message to start different types of servers and clients. Depending on the functional message entered the driver can start TCP servers and clients, UDP servers and clients, servers and clients sending and receiving data using various API calls, sockets that send and receive out-of-band (OOB) data, sockets that run in blocking and non-blocking mode, etc. For more information on how to use and run the driver see Section 2.0 - Syntax Information. 2.

2.0 Syntax Information 2.1.Syntax Diagram: Most of the functional messages are arranged in the way shown below. Note: There are socket functional messages that do not follow this format >>-- -ZTEST----- --SOCK-- --socket----------- --> --protocol--------- --> --type------------- --> ------------------- --> ---ip address-- --> ---port no.---- --> ---msgs-------- --> ---msg_size---- --> ---resends----- --> Where: The SOCK Driver 4/9/02 PARAMETER socket protocol type DESCRIPTION Specifies whether the socket is a server socket or a client socket. For a server socket, specify server. For a client socket, specify client. Specifies whether the socket is the UDP or TCP protocol. For a UDP socket, specify datagram. For a TCP socket specify stream. Note: The nstream and ndatag can also be used to invoke certain drivers (see below) Specifies the type of socket API s and/or socket options that will be used. Available types are: NOAOR AOR TPFTOTPF SELECT AORAOR AORSENDTO SERRC SETSOCKOPT BLOCK NONBLOCK OOB THREADNOAOR THREADAOR THREAD CREM SWEEP NOCONN NOBIND Note: Not all types can be used with every socket and every protocol (see below) 3.

ip address This field is only valid if the socket is a CLIENT. It specifies the IP address of the remote server you wish to communicate with. port no. This field is only valid if the socket is a CLIENT. It specifies the port number of the remote server you wish to communicate with. msgs This field is only valid if the socket is a CLIENT. It specifies the number of messages you wish to send to the server. msg_size This field is only valid if the socket is a CLIENT. It specifies the size of the message you wish to send to the server. resends This field is only valid if the socket is a CLIENT and the protocol is DATAGRAM. It specifies the number of times you want the UDP client to attempt to resend the message without getting a response before it considers the connection dead. function This field is only valid when connecting to servers with the nstream or ndatagr protocol specified. It specifies the type of function you want the driver to perform: PING-PONG : Echo TCP messages back and forth SEND-ONLY: Client just continually sends while server just does reads READ-ONLY: Server just continually sends while client just does reads **** ZTEST SOCK HELP/? can be used to display an on-line help **** 2.2. Sample Invocations The next section is split into servers that can be started and clients that can be started using the socket driver. Each application(server or client) has documented the associated server or client that it can establish connections with as well as a short descriptions of the processing that is involved with the application. The servers also have associated with them the port that the server is bound to so when starting the client to that server, you can specify the correct port. 4.

Server Applications ZTEST SOCK SERVER STREAM NOAOR - segment QXYD (PORT 5003) This application creates a TCP socket binding to IP address IPADDR_ANY and port 5003. It will then issue a listen() and an accept() waiting for a client connection. When the client connects, the application issues a recvfrom() reading the data and immediately issues sendto() to echo the data back to the client. When all the client messages have been read and echoed back, the server will issue another accept waiting for the next connection. Other APIs issued: getsockname(), gethostname(), close(), shutdown() CLIENTS: ZTEST SOCK CLIENT STREAM BLOCK CLNTCONN (For OS/2) ZTEST SOCK SERVER STREAM AOR - segment QXYE (PORT 5004) This application creates a TCP socket binding to IP address IPADDR_ANY and port 5004. It will then issue a listen() and an accept() waiting for a client connection. When the client connects, the application issues an activate_on_receipt() activating program QXYK (which is contained in its own DLM - QXYK). QXYE goes on to issue another accept() waiting for another conenction request. QXYK reads in the clients messages with with read() and echoes the data back to the client with a write(). Other API s that may be issued: getsockname(), gethostname(), close(), shutdown(), getpeername(). CLIENTS: ZTEST SOCK CLIENT STREAM BLOCK CLNTCONN (For OS/2) ZTEST SOCK SERVER DATAGRAM NOAOR - segment QXYB (PORT 5001) This application creates a UDP socket binding to IP address IPADDR_ANY and port 5001. It will then issue a recvfrom() waiting for remote application data and when data is received it will echo the data back with a sendto(). It will continue issuing recvfrom() and sendto() infinitely. Other API s that may be issued: getsockname(), setsockopt(), close(). CLIENTS: ZTEST SOCK CLIENT DATAGRAM BLOCK ZTEST SOCK CLIENT DATAGRAM NOCONN ZTEST SOCK CLIENT DATAGRAM NOBIND CLNTLESS (For OS/2) ZTEST SOCK SERVER DATAGRAM AOR - segment QXYC (PORT 5002) This application creates a UDP socket binding to IP address IPADDR_ANY and port 5002. It will the issue an activate_on_receipt() which will activate segment QXYL (which is contained in its own DLM - QXYL). QXYL issues a recvfrom() and echoes back the data with a sendto(). QXYL will then issue another AOR() activating itself when data arrives. Other API s that may be issued: getsockname(), setsockopt(), shutdown(), close(). CLIENTS: ZTEST SOCK CLIENT DATAGRAM BLOCK ZTEST SOCK CLIENT DATAGRAM NOCONN ZTEST SOCK CLIENT DATAGRAM NOBIND CLNTLESS (For OS/2) 5.

ZTEST SOCK SERVER STREAM TPFTOTPF - segment QXYF (PORT will be assigned TPF) This application creates a TCP socket binding to IP addres IPADDR_ANY and to a port of 0, meaning TPF will assign an available port. The application then issues a listen() and and accept() to wait for client connect requests. When a client connects, the application issues an activate_on_receipt() and when data is available segment QXYM is activated. QXYF loops back to issue another accept() to wait for another connection. QXYM issues read() and echoes back each message the client sends with a write(). When all the messages are read, it closes the socket. Other API s that may be issued: shutdown(), getpeername(), getsockname(), gethostname(). Note: when connecting a client to this server, you have to connect to the port TPF assigned to the server. CLIENTS: ZTEST SOCK CLIENT STREAM CREM ZTEST SOCK SERVER DATAGRAM SELECT - segment QXYI (PORT 5005) This application creates a UDP socket binding it to IP address IPADDR_ANY and port 5005. The application will then go into a loop doing a select() for read. When data arrives, the select() gets posted and the application will issue a recvfrom() and echo the data back with a sendto(). This is an infinite loop with it issuing another select(). Other API s that may be issued: close(), setsockopt(), getsockname(). CLIENTS: ZTEST SOCK CLIENT DATAGRAM BLOCK ZTEST SOCK CLIENT DATAGRAM NOCONN ZTEST SOCK CLIENT DATAGRAM NOBIND CLNTLESS (For OS/2) ZTEST SOCK SERVER STREAM AORAOR - segment QXYJ (PORT 5006) This application creates a TCP socket binding to IP address IPADDR_ANY and port 5006. The server will do a listen() and go into an infinite accept() loop. When a client connects the server will do an activate_on_receipt() and when data is available to read, QXYL will be activated. QXYL will issue read() and echo back the data with a send() until all the clients messages are processed. Other API s that may be issued: close(), shutdown(), getsockname(), gethostname(). CLIENTS: ZTEST SOCK CLIENT STREAM BLOCK CLNTCONN (For OS/2) ZTEST SOCK SERVER STREAM AORSENDTO - segment QXYQ (PORT 5007) This application creates a TCP socket binding to IP address IPADDR_ANY and port 5007. The server will do a listen() and go into an infinite accept() loop. When a client connects the server will do an activate_on_receipt() and when data is available to read, QXYL will be activated. QXYL will issue recvfrom() and echo back the data with a sendto() until all the clients messages are processed. Other API s that may be issued: close(), shutdown(), getsockname(), gethostname(). CLIENTS: ZTEST SOCK CLIENT STREAM BLOCK CLNTCONN (For OS/2) 6.

ZTEST SOCK SERVER STREAM SERRC - segment QXYR (PORT will be assigned TPF) This application creates a TCP socket binding to IP addres IPADDR_ANY and to a port of 0, meaning TPF will assign an available port. The application then issues a listen() and and accept() to wait for client connect requests. When a client connects, the application issues an activate_on_receipt(), which will activate segment QXYM when data becomes available to read. QXYM will issue a read() and echo the data back with a write() until all the messages are processed. As QXYM is processing the client QXYR continues doing accepts. When the fifth client connects, QXYR will issue an OPR dump and exit. Other API s that may be issued: close(), shutdown(), gethostname(), getsockname(), getpeername(). CLIENTS: ZTEST SOCK CLIENT STREAM CREM ZTEST SOCK SERVER STREAM SETSOCKOPT - segment QXYT (PORT 5009) This application creates a TCP socket binding to IP address IPADDR_ANY and port 5009. The application will then issue numerous setsockopt() and getsockopt() API calls to set values for that socket and to display them. The server will then issue a listen() and an accept(), waiting for a client connection. When the connection request is received and the connection is established, the application issues more setsockopt() and getsockopt() APIs on the new socket block. It will then read the data sent by the remote client application and echo it back using read() and send() API s. Other API s that may be issued: close(), shutdown(), gethostname(), getpeername(), getsockname(), gethostid(). CLIENTS: ZTEST SOCK CLIENT STREAM BLOCK CLNTCONN (For OS/2) ZTEST SOCK SERVER STREAM NONBLOCK - segment QXYU (PORT 5010) This application creates a TCP socket binding to IP address IPADDR_ANY and port 5010. The application will the issue a listen() and then do an ioctl() to change the socket to run in non-blocking mode. The server then issues an accept() and goes into a select() loop to verify if a connection request was received. When a connection is established, we CREM to segment QXZX to exchange the data and QXYU will issue another accept waiting for connections. Using, select() for reads and select() for writes, QXZX can API s The SOCK Driver 4/9/02 verify if data is available for read/write and process the data accordingly. Other that may be issued: close(), shutdown(), setsockopt(), getsockopt(). CLIENTS: ZTEST SOCK CLIENT STREAM NONBLOCK 7.

ZTEST SOCK SERVER DATAGRAM NONBLOCK - segment QXYW (PORT 5011) This application creates a UDP socket binding to IP address IPADDR_ANY and port 5011. The application will then do an ioctl() to change the socket to run in non-blocking mode. The server then issues a recvfrom() waiting for data from the client. When data is received, the server will echo the data back using the sendto() API. Other API s that may be issued: close(), setsockopt(), getsockopt(), getsockname(),. CLIENTS: ZTEST SOCK CLIENT DATAGRAM NONBLOCK ZTEST SOCK SERVER STREAM OOB - segment QXZA (PORT 5012) This application creates a TCP socket binding to IP address IPADDR_ANY and port 5012. The application will then do a listen() and accept(), waiting for connection requests. The server will process both OOB data and regular data using the select() API to determine which type of data is on the queue and doing a recv() to read the data. Whatever is sent to the server will be echoed back to the client using the send() API. Other API s that may be issued: setsockopt(), ioctl(), close(). CLIENTS: ZTEST SOCK CLIENT STREAM OOB ZTEST SOCK IP-xxx.xxx.xxx.xxx PORT-yyyyy STYPE-vvv SPROT-zzz AOR-Y/N SELECT-Y/N - segment QXZI Where: xxx.xxx.xxx.xxx is the local IP address to bind to yyyyy is the server port number to bind to vvv is the type of socket to create (UDP/TCP) zzz is the protocol to use (UDP/TCP) The application creates the type of socket specified by the user and issues the functions specified by the user (ie. AOR, SELECT, etc.). Depending on what type of server you create is the way the application will process the data. CLIENTS: ZTEST SOCK CLIENT NSTREAM BLOCK <ip> <port> <# msg> <size> <func> ZTEST SOCK CLIENT NSTREAM NONBLOCK <ip> <port> <# msg> <size> <func> ZTEST SOCK CLIENT NDATAGR BLOCK <ip> <port> <# msg> <size> <func> ZTEST SOCK CLIENT NDATAGR NONBLOCK <ip> <port> <# msg> <size> <func> Note: These drivers were created for the PUT 11 Native Stack project 8.

Client Applications ZTEST SOCK CLIENT DATAGRAM BLOCK < IP ADDR > < PORT # > < # MSGS > < MSG SIZE > < NO. RESEND > - segment QXYG This application creates a UDP socket and issues a bind(), which will bind the socket to the system s default IP address and the next client port in the port number range (1024-5000). The client will issue a connect to the server and begin sending the messages specified by the user on the functional message using the send() API. The message size sent is also specified by the user. The number of resends on input to the application is the number of times to re - send a lost message before breaking the connection. Once all of the messages have been sent and have been echoed back by the server and read using the read() API, we will issue close() to clean up the connection. Other API s that may be issued: setsockopt(), getsockname(), select() SERVERS: ZTEST SOCK SERVER DATAGRAM NOAOR (port 5001) ZTEST SOCK SERVER DATAGRAM AOR (port 5002) ZTEST SOCK SERVER DATAGRAM SELECT (port 5005) SERVLESS (for OS/2) (port 5001) ZTEST SOCK CLIENT STREAM BLOCK < IP ADDR > < PORT # > < # MSGS > < MSG SIZE > - segment QXYH This application creates a TCP socket and issues a bind(), which will bind the socket to the system s default IP address and the next client port in the port number range (1024-5000). The client will issue a connect to the server and begin sending the messages specified by the user on the functional message using the send() API. The message size sent is also specified by the user. Once all of the messages have been sent and have been echoed back by the server and read using the read() API, we will issue close() to clean up the connection. Other API s that may be issued: setsockopt(), getsockname(), select() SERVERS: ZTEST SOCK SERVER STREAM NOAOR (port 5003) ZTEST SOCK SERVER STREAM AOR (port 5004) ZTEST SOCK SERVER STREAM AORAOR (port 5006) ZTEST SOCK SERVER STREAM AORSENDTO (port 5007) 9.

ZTEST SOCK CLIENT STREAM CREM < IP ADDR > < PORT # > < # MSGS > < MSG SIZE > < # CLIENTS > - segment QXYN This application initially enters QXYA (the socket driver parser) and issues CREMC to QXYN for the number of clients specified on input to the driver. The application creates a TCP socket and issues a bind(), which will bind the socket to the system s default IP address and the next client port in the port number range (1024-5000). Each client (created by CREMC) will issue a connect to the server and begin sending the messages specified by the user on the functional message using the write() API. The message size sent is also specified by the user. Once all of the messages have been sent and have been echoed back by the server and read using the read() API, we will issue close() to clean up the connection. Other API s that may be issued: shutdown(). SERVERS: ZTEST SOCK SERVER STREAM TPFTOTPF (port assigned by TPF) ZTEST SOCK CLIENT DATAGRAM SWEEP < IP ADDR > < PORT # > < # MSGS > < MSG SIZE > < NO. RESEND > - segment QXYG This application creates a UDP socket and issues a bind(), which will bind the socket to the system s default IP address and the next client port in the port number range (1024-5000). The client will issue a connect to the server and begin sending the messages specified by the user on the functional message using the send() API. The message size sent is also specified by the user. The number of resends on input to the application is the number of times to re - send a lost message before breaking the connection. Once all of the messages have been sent and have been echoed back by the server and read using the read() API, we will issue close() to clean up the connection. Other API s that may be issued: setsockopt(), getsockname(), select() SERVERS: ZTEST SOCK SERVER DATAGRAM NOAOR (port 5001) ZTEST SOCK SERVER DATAGRAM AOR (port 5002) ZTEST SOCK SERVER DATAGRAM SELECT (port 5005) SERVLESS (for OS/2) (port 5001) 10.

ZTEST SOCK CLIENT STREAM NONBLOCK < IP ADDR > < PORT # > < # MSGS > < MSG SIZE> - segment QXYV This application creates a TCP socket and issues a bind(), which will bind the socket to the system s default IP address and the next client port in the port number range (1024-5000). The client will issue an ioctl() to put the socket in non-blocking mode. The client will issue a connect to the server and begin sending the messages specified by the user on the functional message using the send() API. The message size sent is also specified by the user. Once all of the messages have been sent and have been echoed back by the server and read using the recv() API, we will issue close() to clean up the connection. Other API s that may be issued: setsockopt(), shutdown(), close(), select() SERVERS: ZTEST SOCK SERVER STREAM NOBLOCK (port 5010) ZTEST SOCK CLIENT DATAGRAM NONBLOCK < IP ADDR > < PORT # > < # MSGS > < MSG SIZE> < # RESENDS > - segment QXYX be This application creates a UDP socket and issues a bind(), which will bind the socket to the system s default IP address and the next client port in the port number range (1024-5000). The client will issue an ioctl() to put the socket in non-blocking mode. The client will issue a connect to the server and begin sending the messages specified by the user on the functional message using the send() and sendto() API. The message size sent is also specified by the user. The number of resends on input to the application is the number of times to re - send a lost message before breaking the connection. Once all of the messages have been sent and have been echoed back by the server and read using the recvfrom() API, we will issue close() to clean up the connection. Other API s that may issued: setsockopt(), shutdown(), close(), select() SERVERS: ZTEST SOCK SERVER DATAGRAM NOBLOCK (port 5011) 11.

ZTEST SOCK CLIENT DATAGRAM NOCONN < IP ADDR > < PORT # > < # MSGS > < MSG SIZE > < NO. RESEND > - segment QXYY This application creates a UDP socket and issues a bind(), which will bind the socket to the system s default IP address and the next client port in the port number range (1024-5000). The client will not issue a connect to the server, which causes the communication to be connectionless. The client will begin sending the messages pecified by the user on the functional message using the sendto() API. The message size sent is also specified by the user. The number of resends on input to the application is the number of times to re - send a lost message before breaking the connection. Once all of the messages have been sent and have been echoed back by the server and read using the recvfrom() API, we will issue close() to clean up the connection. Other API s that may be issued: setsockopt(), getsockname(), select() SERVERS: ZTEST SOCK SERVER DATAGRAM NOAOR (port 5001) ZTEST SOCK SERVER DATAGRAM AOR (port 5002) ZTEST SOCK SERVER DATAGRAM SELECT (port 5005) SERVLESS (for OS/2) (port 5001) ZTEST SOCK CLIENT DATAGRAM NOBIND < IP ADDR > < PORT # > < # MSGS > < MSG SIZE > < NO. RESEND > - segment QXYZ This application creates a UDP socket. A bind() is not issued causing the socket to be bound under the covers when sending the first message. The client will not issue a connect to the server, which causes the communication to be connectionless. The client will begin sending the messages specified by the user on the functional message using the sendto() API. The message size sent is also specified by the user. The number of resends on input to the application is the number of times to re - send a lost message before breaking the connection. Once all of the messages have been sent and have been echoed back by the server and read using the recvfrom() API, we will issue close() to clean up the connection. Other API s that may be issued: setsockopt(), getsockname(), select() SERVERS: ZTEST SOCK SERVER DATAGRAM NOAOR (port 5001) ZTEST SOCK SERVER DATAGRAM AOR (port 5002) ZTEST SOCK SERVER DATAGRAM SELECT (port 5005) SERVLESS (for OS/2) (port 5001) 12.

ZTEST SOCK CLIENT STREAM OOB < IP ADDR > < PORT # > < # MSGS > < MSG SIZE > - segment QXZB This application creates a TCP socket and issues a bind(), which will bind the socket to the system s default IP address and the next client port in the port number range (1024-5000). The client will issue a connect to the server and begin sending the messages specified by the user on the functional message using the send() API. These messages will contain OOB data that the server will have to parse out. The message size sent is also specified by the user. Once all of the messages have been sent and have been echoed back by the server and read using the recv() API, we will issue close() to clean up the connection. Other API s that may be issued: setsockopt(), select() SERVERS: ZTEST SOCK SERVER STREAM OOB (port 5012) ZTEST SOCK CLIENT NSTREAM BLOCK <ip> <port> < # msg > < msg size > <function > ZTEST SOCK CLIENT NSTREAM NONBLOCK <ip> <port> < # msg > < msg size > <function > ZTEST SOCK CLIENT NDATAGR BLOCK <ip> <port> < # msg > < msg size > <function > ZTEST SOCK CLIENT NDATAGR NONBLOCK <ip> <port> < # msg > < msg size > <function > SEGMENT - QXY7 These clients connect to many different types of servers. Based on the client driver being NSTREAM or NDATAGR will determine if socket is TCP or UDP, respectively. Then there is the BLOCK or NONBLOCK format, which determines if the client will run in blocking or non-blocking mode. The parameters are: <ip> - IP address of server to connect to <port> - Port of server to connect to <#msg> - Number of messages to send to server <msg size> - Size of messages to send to server <function> - Can be one of the following three SEND-ONLY - Client just sends messages to server does not read any messages in from server READ-ONLY - Client just reads messages from server, does not send any messages to the server PING-PONG - Server and Client ping-pong messages between them. Note: These drivers were created for the PUT 11 Native Stack project Note: Function Test specific test cases can be found in QXZI, what these test cases do can be found in the QXZI segment itself. 13.

3.0 Source Code Information The SOCK driver consists of the following program segments: 3.1. Header Files: 3.2. Target(TPF) code: 3.3. ISO-C DLLs: 3.4. ISO-C DLMs: QXYA Contains: QXYA, QXYB, QXYC, QXYD, QXYE, QXYF, QXYG, QXYH, QXYI, QXYJ, QXYQ, QXYR, QXYS, QXYT, QXYU, QXYV, QXYW, QXYX, QXYZ, QXZA, QXZB, QXZC, QXZD, QXZE, QXZF, QXZG, QXZH, QXZI, QXZJ QXYK Contains: QXYK QXYL Contains: QXYL QXYM Contains: QXYM QXYN Contains: QXYN QXYO Contains: QXYO QXYP Contains: QXYP QXZR Contains: QXZR QXZS Contains: QXZS The SOCK Driver 4/9/02 14.

QXZT Contains: QXZT QXZU Contains: QXZU QXZV Contains: QXZV QXZW Contains: QXZW QXZX Contains: QXZX QXZ3 Contains: QXZ3 QXZO Contains: QXZO QXY7 Contains: QXY7 The SOCK Driver 4/9/02 15.

5.0 Building the Driver 5.1. STUBs to be built: 5.2. MACROs/Header Files 5.3. LLM (aka. Library Link Modules) 5.4. DLM (Dynamic Link Modules) The SOCK Driver 4/9/02 Build Script QXYA QXYK QXYL QXYM QXYN QXYO QXYP QXZR QXZS QXZT QXZU QXZV QXZW QXZX QXZ3 QXZO QXY7 Members to be assembled Members to be compiled QXYA - QXYJ QXYQ - QXYZ QXZA - QXZJ QXYK QXYL QXYM QXYN QXYO QXYP QXZR QXZS QXZT QXZU QXZV QXZW QXZX QXZ3 QXZO QXY7 Compiler Options RENT LONGNAME NOSTART TEST(ALL) OPT(0) 5.5. DLL (Dynamic Link Libraries) 5.6. Target (TPF) Segments 16.

5.7. BAL Segments 5.8. Load Deck The following should be loaded: LOADER CALL PROG QXYA41 LOADER CALL PROG QXYK41 LOADER CALL PROG QXYM41 LOADER CALL PROG QXYN41 LOADER CALL PROG QXYO41 LOADER CALL PROG QXYP41 LOADER CALL PROG QXZR41 LOADER CALL PROG QXZS41 LOADER CALL PROG QXZT41 LOADER CALL PROG QXZU41 LOADER CALL PROG QXZV41 LOADER CALL PROG QXZW41 LOADER CALL PROG QXZX41 LOADER CALL PROG QXZO41 LOADER CALL PROG QXZ341 LOADER CALL PROG QXY741 17.