Commit | Line | Data |
---|---|---|
15637ed4 RG |
1 | .\" Copyright (c) 1990, 1991 The Regents of the University of California. |
2 | .\" All rights reserved. | |
3 | .\" | |
4 | .\" Redistribution and use in source and binary forms, with or without | |
5 | .\" modification, are permitted provided that the following conditions | |
6 | .\" are met: | |
7 | .\" 1. Redistributions of source code must retain the above copyright | |
8 | .\" notice, this list of conditions and the following disclaimer. | |
9 | .\" 2. Redistributions in binary form must reproduce the above copyright | |
10 | .\" notice, this list of conditions and the following disclaimer in the | |
11 | .\" documentation and/or other materials provided with the distribution. | |
12 | .\" 3. All advertising materials mentioning features or use of this software | |
13 | .\" must display the following acknowledgement: | |
14 | .\" This product includes software developed by the University of | |
15 | .\" California, Berkeley and its contributors. | |
16 | .\" 4. Neither the name of the University nor the names of its contributors | |
17 | .\" may be used to endorse or promote products derived from this software | |
18 | .\" without specific prior written permission. | |
19 | .\" | |
20 | .\" THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS'' AND | |
21 | .\" ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE | |
22 | .\" IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE | |
23 | .\" ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR CONTRIBUTORS BE LIABLE | |
24 | .\" FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL | |
25 | .\" DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS | |
26 | .\" OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) | |
27 | .\" HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT | |
28 | .\" LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY | |
29 | .\" OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF | |
30 | .\" SUCH DAMAGE. | |
31 | .\" | |
32 | .\" @(#)tp.4 6.4 (Berkeley) 3/28/91 | |
33 | .\" | |
34 | .Dd March 28, 1991 | |
35 | .Dt TP 4 | |
36 | .Os | |
37 | .Sh NAME | |
38 | .Nm TP | |
39 | .Nd | |
40 | .Tn ISO | |
41 | Transport Protocol | |
42 | .Sh SYNOPSIS | |
43 | .Fd #include <sys/socket.h> | |
44 | .Fd #include <netiso/iso_errno.h> | |
45 | .Fd #include <netiso/tp_param.h> | |
46 | .Fd #include <netiso/tp_user.h> | |
47 | .Ft int | |
48 | .Fn socket "[AF_INET, AF_ISO]" SOCK_SEQPACKET 0 | |
49 | .Sh DESCRIPTION | |
50 | .Pp | |
51 | The | |
52 | .Tn TP | |
53 | protocol provides reliable, flow-controlled, two-way | |
54 | transmission of data and record boundaries. | |
55 | It is a byte-stream protocol and is accessed according to | |
56 | the | |
57 | .Dv SOCK_SEQPACKET | |
58 | abstraction. | |
59 | The | |
60 | .Tn TP | |
61 | protocol makes use of a standard | |
62 | .Tn ISO | |
63 | address format, | |
64 | including a Network Service Access Point, and a Transport Service Entity | |
65 | Selector. | |
66 | Subclass 4 may make use of the internet | |
67 | Internet address format. | |
68 | .Pp | |
69 | Sockets utilizing the tp protocol are either | |
70 | .Dq active | |
71 | or | |
72 | .Dq passive . | |
73 | Active sockets initiate connections to passive | |
74 | sockets. By default | |
75 | .Tn TCP | |
76 | sockets are created active; to create a | |
77 | passive socket the | |
78 | .Xr listen 2 | |
79 | system call must be used | |
80 | after binding the socket with the | |
81 | .Xr bind 2 | |
82 | system call. Only | |
83 | passive sockets may use the | |
84 | .Xr accept 2 | |
85 | call to accept incoming connections. Only active sockets may | |
86 | use the | |
87 | .Xr connect 2 | |
88 | call to initiate connections. | |
89 | .Pp | |
90 | Passive sockets may | |
91 | .Dq underspecify | |
92 | their location to match | |
93 | incoming connection requests from multiple networks. This | |
94 | technique, termed | |
95 | .Dq wildcard addressing , | |
96 | allows a single | |
97 | server to provide service to clients on multiple networks. | |
98 | To create a socket which listens on all networks, the | |
99 | .Tn NSAP | |
100 | portion | |
101 | of the bound address must be void (of length zero). | |
102 | The Transport Selector may still be specified | |
103 | at this time; if the port is not specified the system will assign one. | |
104 | Once a connection has been established the socket's address is | |
105 | fixed by the peer entity's location. The address assigned the | |
106 | socket is the address associated with the network interface | |
107 | through which packets are being transmitted and received. | |
108 | .Pp | |
109 | The | |
110 | .Tn ISO | |
111 | Transport Protocol implemented for | |
112 | .Tn AOS R2 | |
113 | at the University of Wisconsin - Madison, | |
114 | and modified for inclusion in the Berkeley Software Distribution, | |
115 | includes classes 0 and 4 | |
116 | of the | |
117 | .Tn ISO | |
118 | transport protocols | |
119 | as specified in | |
120 | the June 1986 version of | |
121 | .Tn IS | |
122 | 8073. | |
123 | Class 4 of the protocol provides reliable, sequenced, | |
124 | flow-controlled, two-way | |
125 | transmission of data packets with an alternate stop-and-wait data path called | |
126 | the "expedited data" service. | |
127 | Class 0 is essentially a null transport protocol, which is used | |
128 | when the underlying network service provides reliable, sequenced, | |
129 | flow-controlled, two-way data transmission. | |
130 | Class 0 does not provide the expedited data service. | |
131 | The protocols are implemented as a single transport layer entity | |
132 | that coexists with the Internet protocol suite. | |
133 | Class 0 may be used only in the | |
134 | .Tn ISO | |
135 | domain. | |
136 | Class 4 may be used in the Internet domain as well as in the | |
137 | .Tn ISO | |
138 | domain. | |
139 | .Pp | |
140 | Two system calls were modified from the previous | |
141 | release of the Berkeley Software Distribution | |
142 | to permit the support the end-of-transport-service-data-unit | |
143 | .Pq Dv EOTSDU | |
144 | indication, and for the receipt and transmission of user | |
145 | connect, confirm, and disconnect data. | |
146 | See | |
147 | .Xr sendmsg 2 | |
148 | and | |
c2714ef5 | 149 | .Xr recvmsg 2 , |
15637ed4 RG |
150 | and further discussion |
151 | below for the formats of the data in the ancillary data buffer. | |
152 | If the | |
153 | .Dv EOTSDU | |
154 | is not needed, the normal | |
155 | .Xr read 2 , | |
156 | and | |
157 | .Xr write 2 | |
158 | system calls may be used. | |
159 | .Pp | |
160 | Through the | |
161 | .Xr getsockopt | |
162 | and | |
163 | .Xr setsockopt | |
164 | system calls, | |
165 | .Tn TP | |
166 | supports several options | |
167 | to control such things as negotiable options | |
168 | in the protocol and protocol strategies. | |
169 | The options are defined in | |
170 | .Aq Pa netiso/tp_user.h , | |
171 | and are described below. | |
172 | .Pp | |
173 | In the tables below, | |
174 | the options marked with a pound sign | |
175 | .Ql \&# | |
176 | may be used | |
177 | with | |
178 | .Xr setsockopt | |
179 | after a connection is established. | |
180 | Others must be used before the connection | |
181 | is established, in other words, | |
182 | before calling | |
183 | .Xr connect | |
184 | or | |
185 | .Xr accept . | |
186 | All options may be used | |
187 | with | |
188 | .Xr getsockopt | |
189 | before or | |
190 | after a connection is established. | |
191 | .Bl -tag -width TPOPT_PSTATISTICS | |
192 | .It Dv TPOPT_CONN_DATA | |
193 | (char *) [none] | |
194 | .br | |
195 | Data to send on | |
196 | .Xr connect . | |
197 | The passive user may issue a | |
198 | .Xr getsockopt | |
199 | call to retrieve a connection request's user data, | |
200 | after having done the | |
201 | .Xr accept | |
202 | system call without implying confirmation of the connection. | |
203 | .Pp | |
204 | The data may also be retrieved by issuing a | |
205 | .Xr recvmsg | |
206 | request for ancillary data only, | |
207 | without implying confirmation of the connection. | |
208 | The returned | |
209 | .Va cmsghdr | |
210 | will contain | |
211 | .Dv SOL_TRANSPORT | |
212 | for the | |
213 | .Va csmg_level | |
214 | and | |
215 | .Dv TPOPT_CONN_DATA | |
216 | for | |
217 | .Va cmsg_type. | |
218 | .It Dv TPOPT_DISC_DATA \&# | |
219 | (char *) [none] | |
220 | .br | |
221 | Data to send on | |
222 | .Xr close . | |
223 | Disconnect data may be sent by the side initiating the close | |
224 | but not by the passive side ("passive" with respect to the closing | |
225 | of the connection), so there is no need to read disconnect data | |
226 | after calling | |
227 | .Xr close . | |
228 | This may be sent by a | |
229 | .Xr setsockopt | |
230 | system call, or by issuing a | |
231 | .Xr sendmsg | |
232 | request specifying ancillary data only. | |
233 | The user-provided | |
234 | .Va cmsghdr | |
235 | must contain | |
236 | .Dv SOL_TRANSPORT | |
237 | for | |
238 | .Va csmg_level | |
239 | and | |
240 | .Dv TPOPT_DISC_DATA | |
241 | for | |
242 | .Va cmsg_type . | |
243 | Sending of disconnect data will in of itself tear down (or reject) | |
244 | the connection. | |
245 | .It Dv TPOPT_CFRM_DATA \&# | |
246 | (char *) [none] | |
247 | .br | |
248 | Data to send when confirming a connection. | |
249 | This may aslo be sent by a | |
250 | .Xr setsockopt | |
251 | system call, or by issuing a | |
252 | .Xr sendmsg | |
253 | request, as above. | |
254 | Sending of connect confirm data will cause the connection | |
255 | to be confirmed rather than rejected. | |
256 | .It Dv TPOPT_PERF_MEAS \&# | |
257 | Boolean. | |
258 | .br | |
259 | When | |
260 | .Xr true , | |
261 | performance measurements will be kept | |
262 | for this connection. | |
263 | When set before a connection is established, the | |
264 | active side will use a locally defined parameter on the | |
265 | connect request packet; if the peer is another | |
266 | .Tn ARGO | |
267 | implementation, this will cause performance measurement to be | |
268 | turned on | |
269 | on the passive side as well. | |
270 | See | |
271 | .Xr tpperf 8 . | |
272 | .It Dv TPOPT_PSTATISTICS | |
273 | No associated value on input. | |
274 | On output, | |
275 | .Ar struct tp_pmeas . | |
276 | .Pp | |
277 | This command is used to read the performance statistics accumulated | |
278 | during a connection's lifetime. | |
279 | It can only be used with | |
280 | .Xr getsockopt . | |
281 | The structure it returns is described in | |
282 | .Aq Pa netiso/tp_stat.h . | |
283 | See | |
284 | .Xr tpperf 8 . | |
285 | .It Dv TPOPT_FLAGS | |
286 | unsigned integer. [0x0] | |
287 | .br | |
288 | This command can only be used with | |
289 | .Xr getsockopt . | |
290 | See the description of the flags below. | |
291 | .It Dv TPOPT_PARAMS | |
292 | .Ar struct tp_conn_param | |
293 | .br | |
294 | Used to get or set a group parameters for a connection. | |
295 | The | |
296 | .Ar struct tp_conn_param | |
297 | is the argument used with the | |
298 | .Xr getsockopt | |
299 | or | |
300 | .Xr setsockopt | |
301 | system call. | |
302 | It is described in | |
303 | .Aq Pa netiso/tp_user.h . | |
304 | .Pp | |
305 | The fields of the | |
306 | .Ar tp_conn_param | |
307 | structure are | |
308 | described below. | |
309 | .El | |
310 | .Pp | |
311 | .Em Values for TPOPT_PARAMS: | |
312 | .Bl -tag -width p_sendack_ticks | |
313 | .It Ar p_Nretrans | |
314 | nonzero short integer [1] | |
315 | .br | |
316 | Number of times a TPDU | |
317 | will be retransmitted before the | |
318 | local TP entity closes a connection. | |
319 | .It Ar p_dr_ticks | |
320 | nonzero short integer [various] | |
321 | .br | |
322 | Number of clock ticks between retransmissions of disconnect request | |
323 | TPDUs. | |
324 | .It Ar p_dt_ticks | |
325 | nonzero short integer [various] | |
326 | .br | |
327 | Number of clock ticks between retransmissions of data | |
328 | TPDUs. | |
329 | This parameter applies only to class 4. | |
330 | .It Ar p_cr_ticks | |
331 | nonzero short integer [various] | |
332 | .br | |
333 | Number of clock ticks between retransmissions of connection request | |
334 | TPDUs. | |
335 | .It Ar p_cc_ticks | |
336 | nonzero short integer [various] | |
337 | .br | |
338 | Number of clock ticks between retransmissions of connection confirm | |
339 | TPDUs. | |
340 | This parameter applies only to class 4. | |
341 | .It Ar p_x_ticks | |
342 | nonzero short integer [various] | |
343 | .br | |
344 | Number of clock ticks between retransmissions of expedited data | |
345 | TPDUs. | |
346 | This parameter applies only to class 4. | |
347 | .It Ar p_sendack_ticks | |
348 | nonzero short integer [various] | |
349 | .br | |
350 | Number of clock ticks that the local TP entity | |
351 | will wait before sending an acknowledgment for normal data | |
c2714ef5 | 352 | (not applicable if the acknowledgement strategy is |
15637ed4 RG |
353 | .Dv TPACK_EACH ) . |
354 | This parameter applies only to class 4. | |
355 | .It Ar p_ref_ticks | |
356 | nonzero short integer [various] | |
357 | .br | |
358 | Number of clock ticks for which a reference will | |
359 | be considered frozen after the connection to which | |
360 | it applied is closed. | |
361 | This parameter applies to classes 4 and 0 in the | |
362 | .Tn ARGO | |
363 | implementation, despite the fact that | |
364 | the frozen reference function is required only for | |
365 | class 4. | |
366 | .It Ar p_inact_ticks | |
367 | nonzero short integer [various] | |
368 | .br | |
369 | Number of clock ticks without an incoming packet from the peer after which | |
370 | .Tn TP | |
371 | close the connection. | |
372 | This parameter applies only to class 4. | |
373 | .It Ar p_keepalive_ticks | |
374 | nonzero short integer [various] | |
375 | .br | |
376 | Number of clock ticks between acknowledgments that are sent | |
377 | to keep an inactive connection open (to prevent the peer's | |
378 | inactivity control function from closing the connection). | |
379 | This parameter applies only to class 4. | |
380 | .It Ar p_winsize | |
381 | short integer between 128 and 16384. [4096 bytes] | |
382 | .br | |
383 | The buffer space limits in bytes for incoming and outgoing data. | |
384 | There is no way to specify different limits for incoming and outgoing | |
385 | paths. | |
386 | The actual window size at any time | |
387 | during the lifetime of a connection | |
388 | is a function of the buffer size limit, the negotiated | |
389 | maximum TPDU | |
390 | size, and the | |
391 | rate at which the user program receives data. | |
392 | This parameter applies only to class 4. | |
393 | .It Ar p_tpdusize | |
394 | unsigned char between 0x7 and 0xd. | |
395 | [0xc for class 4] [0xb for class 0] | |
396 | .br | |
397 | Log 2 of the maximum TPDU size to be negotiated. | |
398 | The | |
399 | .Tn TP | |
400 | standard | |
401 | .Pf ( Tn ISO | |
402 | 8473) gives an upper bound of | |
403 | 0xd for class 4 and 0xb for class 0. | |
404 | The | |
405 | .Tn ARGO | |
406 | implementation places upper bounds of | |
407 | 0xc on class 4 and 0xb on class 0. | |
408 | .It Ar p_ack_strat | |
409 | .Dv TPACK_EACH | |
410 | or | |
411 | .Dv TPACK_WINDOW. | |
412 | .Bq Dv TPACK_WINDOW | |
413 | .br | |
414 | This parameter applies only to class 4. | |
415 | Two acknowledgment strategies are supported: | |
416 | .Pp | |
417 | .Dv TPACK_EACH means that each data TPDU | |
418 | is acknowledged | |
419 | with an AK TPDU. | |
420 | .Pp | |
421 | .Dv TPACK_WINDOW | |
422 | means that upon receipt of the packet that represents | |
423 | the high edge of the last window advertised, and AK TPDU is generated. | |
424 | .It Ar p_rx_strat | |
425 | 4 bit mask | |
426 | .Bq Dv TPRX_USE_CW No \&|\ Dv TPRX_FASTSTART | |
427 | over | |
428 | connectionless network protocols] | |
429 | .Pf [ Dv TPRX_USE_CW | |
430 | over | |
431 | connection-oriented network protocols] | |
432 | .br | |
433 | This parameter applies only to class 4. | |
434 | The bit mask may include the following values: | |
435 | .Pp | |
436 | .Dv TPRX_EACH : | |
437 | When a retransmission timer expires, retransmit | |
438 | each packet in the send window rather than | |
439 | just the first unacknowledged packet. | |
440 | .Pp | |
441 | .Dv TPRX_USE_CW : | |
442 | Use a "congestion window" strategy borrowed | |
443 | from Van Jacobson's congestion window strategy for TCP. | |
444 | The congestion window size is set to one whenever | |
445 | a retransmission occurs. | |
446 | .Pp | |
447 | .Dv TPRX_FASTSTART : | |
448 | Begin sending the maximum amount of data permitted | |
449 | by the peer (subject to availability). | |
450 | The alternative is to start sending slowly by | |
451 | pretending the peer's window is smaller than it is, and letting | |
452 | it slowly grow up to the real peer's window size. | |
453 | This is to smooth the effect of new connections on a congested network | |
454 | by preventing a transport connection from suddenly | |
455 | overloading the network with a burst of packets. | |
456 | This strategy is also due to Van Jacobson. | |
457 | .It Ar p_class | |
458 | 5 bit mask | |
459 | .Bq Dv TP_CLASS_4 No \&|\ Dv TP_CLASS_0 | |
460 | .br | |
461 | Bit mask including one or both of the values | |
462 | .Dv TP_CLASS_4 | |
463 | and | |
464 | .Dv TP_CLASS_0 . | |
465 | The higher class indicated is the preferred class. | |
466 | If only one class is indicated, negotiation will not occur | |
467 | during connection establishment. | |
468 | .It Ar p_xtd_format | |
469 | Boolean. | |
470 | [false] | |
471 | .br | |
472 | Boolean indicating that extended format shall be negotiated. | |
473 | This parameter applies only to class 4. | |
474 | .It Ar p_xpd_service | |
475 | Boolean. | |
476 | [true] | |
477 | .br | |
478 | Boolean indicating that | |
479 | the expedited data transport service will be negotiated. | |
480 | This parameter applies only to class 4. | |
481 | .It Ar p_use_checksum | |
482 | Boolean. | |
483 | [true] | |
484 | .br | |
485 | Boolean indicating the the use of checksums will be negotiated. | |
486 | This parameter applies only to class 4. | |
487 | .It Ar p_use_nxpd | |
488 | Reserved for future use. | |
489 | .It Ar p_use_rcc | |
490 | Reserved for future use. | |
491 | .It Ar p_use_efc | |
492 | Reserved for future use. | |
493 | .It Ar p_no_disc_indications | |
494 | Boolean. | |
495 | [false] | |
496 | .Pp | |
497 | Boolean indicating that the local | |
498 | .Tn TP | |
499 | entity shall not issue | |
500 | indications (signals) when a | |
501 | .Tn TP | |
502 | connection is disconnected. | |
503 | .It Ar p_dont_change_params | |
504 | Boolean. [false] | |
505 | .br | |
506 | If | |
507 | .Em true | |
508 | the | |
509 | .Tn TP | |
510 | entity will not override | |
511 | any of the other values given in this structure. | |
512 | If the values cannot be used, the | |
513 | .Tn TP | |
514 | entity will drop, disconnect, | |
515 | or refuse to establish the connection to which this structure pertains. | |
516 | .It Ar p_netservice | |
517 | One of { | |
518 | .Dv ISO_CLNS , | |
519 | .Dv ISO_CONS , | |
520 | .Dv ISO_COSNS , | |
521 | .Dv IN_CLNS } . | |
522 | .Pf [ Dv ISO_CLNS ] | |
523 | .br | |
524 | Indicates which network service is to be used. | |
525 | .Pp | |
526 | .Dv ISO_CLNS | |
527 | indicates the connectionless network service provided | |
528 | by CLNP | |
529 | .Pf ( Tn ISO | |
530 | 8473). | |
531 | .Pp | |
532 | .Dv ISO_CONS | |
533 | indicates the connection-oriented network service provided | |
534 | by X.25 | |
535 | .Pf ( Tn ISO | |
536 | 8208) and | |
537 | .Tn ISO | |
538 | 8878. | |
539 | .Pp | |
540 | .Dv ISO_COSNS | |
541 | indicates the | |
542 | connectionless network service running over a | |
543 | connection-oriented subnetwork service: CLNP | |
544 | .Pf ( Tn ISO | |
545 | 8473) over X.25 | |
546 | .Pf ( Tn ISO | |
547 | 8208). | |
548 | .Pp | |
549 | .Dv IN_CLNS | |
550 | indicates the | |
551 | DARPA Internet connectionless network service provided by IP (RFC 791). | |
552 | .It Ar p_dummy | |
553 | Reserved for future use. | |
554 | .El | |
555 | .Pp | |
556 | The | |
557 | .Dv TPOPT_FLAGS | |
558 | option is used for obtaining | |
559 | various boolean-valued options. | |
560 | Its meaning is as follows. | |
561 | The bit numbering used is that of the RT PC, which means that bit | |
562 | 0 is the most significant bit, while bit 8 is the least significant bit. | |
563 | .sp 1 | |
564 | .Em Values for TPOPT_FLAGS: | |
565 | .Bl -tag -width Bitsx | |
566 | .It Sy Bits | |
567 | .Sy Description [Default] | |
568 | .It \&0 | |
569 | .Dv TPFLAG_NLQOS_PDN : | |
570 | set when the quality of the | |
571 | network service is | |
572 | similar to that of a public data network. | |
573 | .It \&1 | |
574 | .Dv TPFLAG_PEER_ON_SAMENET : | |
575 | set when the peer | |
576 | .Tn TP | |
577 | entity | |
578 | is considered to be on the same network as the local | |
579 | .Tn TP | |
580 | entity. | |
581 | .It \&2 | |
582 | Not used. | |
583 | .It \&3 | |
584 | .Dv TPFLAG_XPD_PRES : | |
585 | set when expedited data are present | |
586 | [0] | |
587 | .It 4\&..7 | |
588 | Reserved. | |
589 | .El | |
590 | .Sh ERROR VALUES | |
591 | .Pp | |
592 | The | |
593 | .Tn TP | |
594 | entity returns | |
595 | .Va errno | |
596 | error values as defined in | |
597 | .Aq Pa sys/errno.h | |
598 | and | |
599 | .Aq Pa netiso/iso_errno.h . | |
600 | User programs may print messages associated with these value by | |
601 | using an expanded version of | |
602 | .Xr perror | |
603 | found in the | |
604 | .Tn ISO | |
605 | library, | |
606 | .Pa libisodir.a . | |
607 | .Pp | |
608 | If the | |
609 | .Tn TP | |
610 | entity encounters asynchronous events | |
611 | that will cause a transport connection to be closed, | |
612 | such as | |
613 | timing out while retransmitting a connect request TPDU, | |
614 | or receiving a DR TPDU, | |
615 | the | |
616 | .Tn TP | |
617 | entity issues a | |
618 | .Dv SIGURG | |
619 | signal, indicating that | |
620 | disconnection has occurred. | |
621 | If the signal is issued during a | |
622 | a system call, the system call may be interrupted, | |
623 | in which case the | |
624 | .Va errno | |
625 | value upon return from the system call is | |
626 | .Er EINTR. | |
627 | If the signal | |
628 | .Dv SIGURG | |
629 | is being handled by reading | |
630 | from the socket, and it was a | |
631 | .Xr accept 2 | |
632 | that | |
633 | timed out, the read may result in | |
634 | .Er ENOTSOCK , | |
635 | because the | |
636 | .Xr accept | |
637 | call had not yet returned a | |
638 | legitimate socket descriptor when the signal was handled. | |
639 | .Dv ETIMEDOUT | |
640 | (or a some other errno value appropriate to the | |
641 | type of error) is returned if | |
642 | .Dv SIGURG | |
643 | is blocked | |
644 | for the duration of the system call. | |
645 | A user program should take one of the following approaches: | |
646 | .Bl -tag -width Ds | |
647 | .It Block Dv SIGURG | |
648 | If the program is servicing | |
649 | only one connection, it can block or ignore | |
650 | .Dv SIGURG | |
651 | during connection | |
652 | establishment. | |
653 | The advantage of this is that the | |
654 | .Va errno | |
655 | value | |
656 | returned is somewhat meaningful. | |
657 | The disadvantage of this is that | |
658 | if ignored, disconnection and expedited data indications could be | |
659 | missed. | |
660 | For some programs this is not a problem. | |
661 | .It Handle Dv SIGURG | |
662 | If the program is servicing more than one connection at a time | |
663 | or expedited data may arrive or both, the program may elect to | |
664 | service | |
665 | .Dv SIGURG . | |
666 | It can use the | |
667 | .Fn getsockopt ...TPOPT_FLAGS... | |
668 | system | |
669 | call to see if the signal | |
670 | was due to the arrival of expedited data or due to a disconnection. | |
671 | In the latter case, | |
672 | .Xr getsockopt | |
673 | will return | |
674 | .Er ENOTCONN . | |
675 | .El | |
676 | .Sh SEE ALSO | |
677 | .Xr tcp 4 , | |
678 | .Xr netstat 1 , | |
679 | .Xr iso 4 , | |
680 | .Xr clnp 4 , | |
681 | .Xr cltp 4 , | |
682 | .Xr ifconfig 8 . | |
683 | .Sh HISTORY | |
684 | The | |
685 | .Nm | |
686 | protocol | |
687 | .Ud | |
688 | .Sh BUGS | |
689 | The protocol definition of expedited data is slightly problematic, | |
690 | in a way that renders expedited data almost useless, | |
691 | if two or more packets of expedited data are send within | |
692 | time epsilon, where epsilon | |
693 | depends on the application. | |
694 | The problem is not of major significance since most applications | |
695 | do not use transport expedited data. | |
696 | The problem is this: | |
697 | the expedited data acknowledgment TPDU | |
698 | has no field for conveying | |
699 | credit, thus it is not possible for a | |
700 | .Tn TP | |
701 | entity to inform its peer | |
702 | that "I received your expedited data but have no room to receive more." | |
703 | The | |
704 | .Tn TP | |
705 | entity has the choice of acknowledging receipt of the | |
706 | XPD TPDU: | |
707 | .Bl -tag -width Ds | |
708 | .It "when the user receives the" XPD TSDU | |
709 | which may be a fairly long time, | |
710 | which may cause the sending | |
711 | .Tn TP | |
712 | entity to retransmit the packet, | |
713 | and possibly to close the connection after retransmission, or | |
714 | .It "when the" Tn TP No "entity receives it" | |
715 | so the sending entity does not retransmit or close the connection. | |
716 | If the sending user then tries to send more expedited data | |
717 | .Dq soon , | |
718 | the expedited data will not be acknowledged (until the | |
719 | receiving user receives the first XPD TSDU). | |
720 | .El | |
721 | .Pp | |
722 | The | |
723 | .Tn ARGO | |
724 | implementation acknowledges XPD TPDUs | |
725 | immediately, | |
726 | in the hope that most users will not use expedited data requently | |
727 | enough for this to be a problem. |