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