| DISCUSSIONS: |
- From September 28th, 1998 Meeting in Savannah, GA
- Server Provider Interface for 1394 PWG Transport Protocol
- SPI Presentation slides to be posted to Web Site.
- Clients
- Clients are Applications that use the transport;
- discover and connect to Servers
- transfer data
- disconnect from servers
- monitor errors and asynchronous events
- Servers
- Server is one of those Applications that provides services.
- identify themselves—usually with a service name
- accept connections from Clients
- transfer data
- disconnect from clients(?)
- monitor errors and asynchronous events
- Generalization: Clients often reside in a host - Servers reside in a device.
- Socket-based Interface:
- a standard API for transport protocols
- a data structure pointing to an application
- data structure points to only one application
- application may have more than one data structures pointing to it
- BSD and Winsock-2 are well-known socket interfaces
- Suggested Services:
- Socket
- Bind
- Listen
- Shutdown
- Accept
- Connect
- Send
- Receive
- SetSockOpt
- GetSockOpt
- Usage by of the Service Provider by Clients and Servers
- Clients
- establish a socket by calling Socket
- once a socket is allocated, Client can request a connection
- when Client is finished using a socket it releases the socket by calling Shutdown
- once a connection is open, Clients can Send and Receive data
- Servers
- establish a socket and Bind their service name to that socket
- once allocated, Servers call Listen to establish an incoming request queue
- after requesting a connection, Accept will complete with a new socket for the open connection
- once a connection is open, Servers can Send and Receive data
- Discussion
- Points raised
- Consider further discussions of a socket-based interface as a "case study" for possible implementation.
- It is believed that this approach should help the group in determining a sufficient list of necessary services for the interface.
- Each of the suggested Services was discussed (A good reference is the Winsock specification.)
- A socket internal data structure will present itself to the bus and indicate its existence as a LUN in the Config ROM
- Each Login is mapped to a socket
- A Login is a pair of connected sockets
- Each LUN is mapped to a Server
- Issues
- How do we support multiple Logins from the same Initiator to the same service?
- Multiplexing either above or below the LUN layer, but which?
- Multiplexing done above the LUN layer, it would work with some implementations that can only support a single LUN
- Do we want to achieve multiple connections (LUNs?) within a single Login?
- Noted that there would be more effort/overhead to support multiple connections within a single Login to:
- avoid blocking
- handle Abort Task Set
- Points out that the SBP-2 model is not fleshed out yet. See additional notes from this meeting on the SBP-2 Stack (980302-012).
- Update of issue from April 13th, 1999 Meeting in New Orleans, LA
- Proposed Sample API for the 1394PWG Transport Protocol
- Document Name: API_020.pdf
- This is a sample that will be included in the documentation.
- This standard will not DEFINE an API.
- Based on Winsock API.
- For general info on Winsock go to www.winsock.com.
|
