|
|
1.1 root 1: .TH LIBACSAP 3N "23 Sep 1986"
2: .\" $Header: /f/osi/acsap/RCS/libacsap.3n,v 7.0 89/11/23 21:22:14 mrose Rel $
3: .\"
4: .\"
5: .\" $Log: libacsap.3n,v $
6: .\" Revision 7.0 89/11/23 21:22:14 mrose
7: .\" Release 6.0
8: .\"
9: .SH NAME
10: libacsap \- Application Control Services library
11: .SH SYNOPSIS
12: .B "#include <isode/acsap.h>"
13: .sp
14: \fIcc\fR\0...\0\fB\-lacsap\fR
15: .SH DESCRIPTION
16: The \fIlibacsap\fR library contains a set of routine which implement
17: association control services.
18: In essence,
19: they implement an Association Control Service Entity (ACSE) interface for
20: user applications.
21: .PP
22: Although the ISO model is symmetric,
23: this implmentation is based on a client/server paradigm and hence asymmetric.
24: The information herein is skeltal:
25: consult the \fIUser's Manual\fR for actual examples of how ISO servers and
26: clients are coded and interact with the \fIlibacsap\fR library.
27: .SH ADDRESSES
28: Two objects are used to address an application using an ACSE:
29: application entity information and a presentation address.
30: The former object denotes the particular application desired;
31: the latter denotes where this application is located.
32: .SH "SERVER INITIALIZATION"
33: A program providing an ISO service is usually invoked under \fItsapd\fR\0(8c),
34: with the argument vector listed in the ISODE services database.
35: The server's very first action is to re\-capture the ACSE state as
36: recorded by \fItsapd\fR.
37: This is accomplished by calling \fBAcInit\fR.
38: Information returned by this call is equivalent to the parameters passed by a
39: A\-ASSOCIATE.INDICATION event.
40: If the call is successful,
41: the program can then examine the argument vector that was passed via
42: \fIexecvp\fR
43: (it's important to call \fBAcInit\fR prior to reading \fBargc\fR and
44: \fBargv\fR).
45: If the call to \fBAcInit\fR is not successful,
46: information returned by the call indicates the reason for failure.
47: .PP
48: After examining the information provided by \fBAcInit\fR
49: (and possibly the argument vector),
50: the server should either accept or reject the connection.
51: If accepting, the \fBAcAssocResponse\fR routine is called with the parameter
52: \fBstatus\fR set to
53: .sp
54: .in +.5i
55: .nf
56: .ta \w'ACS_NOTSPECIFIED 'u
57: ACS_ACCEPT association accepted
58: .re
59: .fi
60: .in -.5i
61: .sp
62: (which corresponds to the accepting A\-ASSOCIATE.RESPONSE action).
63: If the call is successful,
64: the interaction is henceforth symmetric.
65: If un\-successful,
66: information returned by the call indicates the reason for failure.
67: If rejecting, the \fBAcAssocResponse\fR routine is also called,
68: but with the parameter \fBstatus\fR set to one of:
69: .sp
70: .in +.5i
71: .nf
72: .ta \w'ACS_NOTSPECIFIED 'u
73: ACS_PERMANENT permanent
74: ACS_TRANSIENT transient
75: .re
76: .fi
77: .in -.5i
78: .sp
79: (which corresponds to the refusing A\-ASSOCIATE.RESPONSE action),
80: and the program may exit.
81: .SH "CLIENT INITIALIZATION"
82: A program requesting an ISO service calls \fBAcAssocRequest\fR
83: (which corresponds to the A\-ASSOCIATE.REQUEST action).
84: If successful (depending on the responder's choice of \fBresult\fR),
85: the interaction is henceforth symmetric.
86: If un\-successful,
87: information returned by the call indicates the reason for failure.
88: .SH ASSOCIATION\-DESCRIPTORS
89: Once a connection has been established via a successful return from
90: \fBAcAssocResponse\fR (for servers) or \fBAcAssocRequest\fR (for clients),
91: a connection is referenced by a small integer
92: (returned in a structure passed to these calls) called a
93: \fIassociation\-descriptor\fR.
94: This association\-descriptor appears as an argument to the other application
95: service elements being used by the application
96: (e.g., the reliable transfer service entity (RTSE), or the
97: remote operates service entity (ROSE)).
98: .SH "ASSOCIATION RELEASE"
99: The routine \fBAcRelRequest\fR is used to release an association.
100: This triggers a P\-RELEASE.INDICATION event for the other peer.
101: The peer should use the \fBAcFINISHser\fR routine to map this into an
102: A\-RELEASE.INDICATION event.
103: It should then use the routine \fBAcRelResponse\fR to either accept or reject
104: the request to release the association.
105: .SH "ASSOCIATION ABORT"
106: The routine \fBAcUAbortRequest\fR is used to unilaterally abort an
107: association.
108: This triggers a P\-U\-ABORT.INDICATION event for the other peer.
109: The peer should use the \fBAcABORTser\fR routine to map this into an
110: A\-ABORT.INDICATION event.
111: .PP
112: Finally,
113: the routine \fBAcErrString\fR takes a failure code from a \fBAcSAPabort\fR
114: structure and returns a null\-terminated diagnostic string.
115: .SH FILES
116: .nf
117: .ta \w'\*(EDisoservices 'u
118: \*(EDisoentities ISODE entities database
119: \*(EDisobjects ISODE objects database
120: \*(EDisoservices ISODE services database
121: .re
122: .fi
123: .SH "SEE ALSO"
124: isoentities(5), isobjects (5), isoservices(5), tsapd(8c),
125: .br
126: \fIThe ISO Development Environment: User's Manual\fR,
127: .br
128: ISO 8649:
129: \fIInformation Processing Systems \-\- Open Systems Interconnection
130: \-\-
131: Service Definition for the Association Control Service Element\fR,
132: .SH DIAGNOSTICS
133: All routines return the manifest constant \fBNOTOK\fR (\-1) on error.
134: In addition,
135: those routines which take a pointer to a \fBAcSAPindication\fR structure
136: fill\-in the structure as appropriate.
137: .SH AUTHOR
138: Marshall T. Rose
139: .SH BUGS
140: Do not confuse association\-descriptors with file\-descriptors.
141: Unlike file\-descriptors which are implemented by the kernel,
142: association\-descriptors do not work across \fIfork\fRs and \fIexec\fRs.
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.