RFC 938
Internet Reliable Transaction Protocol functional and interface specification
RFC 938: Internet Reliable Transaction Protocol 🎀
Functional and Interface Specification
Part 1 of 4 💖
Okay bestie, the title block first! 📋 This is RFC 938, written by Trudy Miller from ACC, dated February 1985. It was filed under the Network Working Group. The title block doesn't list any RFCs that this one obsoletes or updates, and there isn't a formal category line either. The Status section explains what it's for: it's a proposal that's being passed around for feedback. 🦋
STATUS OF THIS MEMO ✨
This RFC is going out to members of the DARPA research community so they can react to the proposals in it. The issues it covers might not be directly related to what DARPA researchers are working on, but plenty of researchers and implementors could still find them interesting. It suggests a protocol for the ARPA-Internet community and asks for discussion and ideas for improvements. Distribution of this memo is unlimited. 🌸
ABSTRACT 💜
The Internet Reliable Transaction Protocol (IRTP) is a host to host protocol that works at the transport level, and it's built for an internet environment. It gives you reliable, sequenced delivery of data packets between hosts. It also multiplexes and demultiplexes streams of packets to and from user processes, which are identified by ports. It's simple to implement and needs very little connection management, though that might cost some efficiency. 🧚
TABLE OF CONTENTS 📚
INTRODUCTION
1.1 Purpose ......................................... 1
1.2 Underlying Mechanisms ........................... 1
1.3 Relationship to Other Protocols ................. 2
IRTP HEADERS
2.1 Header Format ................................... 3
2.2 Packet Type ..................................... 3
2.3 Port Number ..................................... 3
2.4 Sequence Number ................................. 4
2.5 Length .......................................... 4
2.6 Checksum ........................................ 4
INTERFACES
3.1 User Services Provided By IRTP .................. 5
3.2 IP Services Expected by IRTP .................... 5
MODEL OF OPERATION
4.1 State Variables ................................. 6
4.2 IRTP Initialization ............................. 7
4.3 Host-to-Host Synchronization .................... 7
4.3.1 Response to SYNCH Packets ..................... 7
4.3.2 Response to SYNCH ACK Packet .................. 8
4.4 Transmitting Data ............................... 8
4.4.1 Receiving Data From Using Processes ........... 8
4.4.2 Packet Retransmission ......................... 10
4.5 Receiving Data .................................. 10
4.5.1 Receive and Acknowledgment Windows ............ 11
4.5.2 Invalid Packets ............................... 12
4.5.3 Sequence Numbers Within Acknowledge Window .... 12
4.5.4 Sequence Numbers Within the Receive Window .... 12
4.5.5 Forwarding Data to Using Processes ............ 13
IMPLEMENTATION ISSUES
5.1 Retransmission Strategies ....................... 14
5.2 Pinging ......................................... 14
5.3 Deleting Connection Tables ...................... 16
LIST OF FIGURES
Figure 1-1 Relationship of IRTP to Other Protocols . 2
Figure 2-1 IRTP Header Format ...................... 3
Figure 4-1 SYNCH Packet Format ..................... 8
Figure 4-2 SYNCH ACK Packet Format ................. 8
Figure 4-3 DATA Packet Format ...................... 9
Figure 4-4 DATA ACK Packet Format .................. 11
Figure 4-5 PORT NAK Packet Format .................. 11
ABBREVIATIONS
ICMP Internet Control Message Protocol
IP Internet Protocol
IRTP Internet Reliable Transaction Protocol
RDP Reliable Data Protocol
TCP Transmission Control Protocol
UDP User Datagram ProtocolCHAPTER 1 - INTRODUCTION 🌈
IRTP is a full duplex, host to host protocol that's built around transactions. It gives reliable, sequenced delivery of data packets, and those packets are called transaction packets. 💅
Note: throughout this document, the terms host and internet address are used interchangeably. 🙈
1.1 Purpose
IRTP was made for an environment where one host has to stay in reliable contact with lots of other hosts. The flow of information with each destination host is assumed to be (relatively) sporadic, but information can start flowing at any time from either end of the connection. The information comes in the form of transactions, which are small, self-contained messages. Sometimes one host will want to send essentially the same information to all of its known destinations, and it'll want to do that as fast as possible. 🦋
Basically, IRTP sets up a constant underlying connection between two hosts. That connection isn't established and torn down over and over. Instead, it can be resynchronized with minimal data loss whenever one of the hosts has been rebooted. ✨
Because there's no real connection management, it's desirable for all IRTP processes to keep static information about every possible remote host. The good news is that IRTP is designed so each host to host pair only needs minimal state information. That lets one host talk to many remote hosts. 🧚
IRTP is more involved than UDP, since it gives reliable, sequenced delivery of packets. But it's simpler than TCP, because sequencing happens packet by packet instead of over a character stream. Also, only one connection is defined between any two internet addresses. So it isn't a process to process protocol. 💀
1.2 Underlying Mechanisms
IRTP uses retransmission and acknowledgments to guarantee delivery. Checksums are used to guarantee data integrity and to protect against misrouting. There's a host to host synchronization mechanism, plus packet sequencing, which gives duplicate detection and ordered delivery to the user process. There's also a simple mechanism that lets IRTP multiplex and demultiplex streams of transaction packets. Those streams are exchanged between multiple IRTP users on this host and statically paired IRTP users on the same remote host. 👑
1.3 Relationship to Other Protocols
IRTP is designed for use in a potentially lossy internet environment. It requires that IP be under it. The IP protocol number of IRTP is 28. 🍓
IRTP also provides a reliable transport protocol for one or more user processes. User processes must have well-known IRTP port numbers, and they can only communicate with matching processes that have the same port number. (Quick note: the term port refers to a higher level protocol. IRTP connections exist between two hosts, not between a host/port and another host/port.) 🎀
Here's how it all fits together:
+--------+ +--------+ +-----------+
| port a |....| port x | | TCP users | Application Level
+--------+ +--------+ +-----------+
| | | ... |
+--------------+ +-----------+
| IRTP | | TCP | Host Level
+--------------+ +-----------+
| |
+--------------------------------------+
| Internet Protocol and ICMP | Internet Level
+--------------------------------------+
|
+--------------------------------------+
| Local Network Protocol | Network Level
+--------------------------------------+
Figure 1-1. Relationship of IRTP to Other ProtocolsCHAPTER 2 - IRTP HEADERS 🦄
2.1 Header Format
Every IRTP packet starts with an eight byte header. The diagram below shows it, and the fields are explained in the sections that follow. 📦
0 7 8 15 16 31
+--------+--------+--------+--------+
| packet | port | sequence |
| type | number | number |
+--------+--------+--------+--------+
| length | checksum |
| | |
+-----------------+-----------------+
| |
| optional data octets |
+ . . . . . . . . . . . . . . . . . |
Figure 2-1. IRTP Header Format2.2 Packet Type
IRTP defines five packet types. Here they are: 🌸
packet type numeric code
SYNCH 0
SYNCH ACK 1
DATA 2
DATA ACK 3
PORT NAK 4The section MODEL OF OPERATION talks about how each individual packet type gets used. 🫶
2.3 Port Number
The port number field handles multiplexing and demultiplexing of packets from multiple user processes over one IRTP connection. Any process that wants to use IRTP has to claim port numbers. A port number stands for a higher level protocol. Data going to or from a port can only be exchanged with a process that claimed the same port number on a remote host. A process can claim multiple port numbers, but only one process can claim any given port number. Every port number is well-known. ✨
2.4 Sequence Number
For each pair of communicating hosts, there are two sequence numbers defined. They're the send sequence numbers for the two ends. Sequence numbers are treated as unsigned 16 bit integers. Every time a new transaction packet gets sent, the sender bumps its sequence number up by one. Initial sequence numbers are set up when the connection is resynchronized (see Section 4.3.) 🔥
2.5 Length
The length is the number of octets in this transaction packet, counting both the header and the data. (That means the minimum value of the length is 8.) 💜
2.6 Checksum
The checksum is the 16-bit one's complement of the one's complement sum of the IRTP header and the transaction packet data. If the data has an odd number of octets, it gets padded with one octet of zero so the total comes out even. 🌈
3. Interfaces ✨
3.1 User Services Provided by IRTP 💖
Okay so the exact interface between the TRTP and the using processes is implementation dependent 🤷♀️, but IRTP SHOULD still give the using processes these services 🎀:
- user processes MUST be able to claim a port number 🌸
- users MUST be able to request that data be sent to a particular port at an internet address (the port MUST be one which the user has claimed) 🦋
- users MUST be able to request transaction data from a particular port at any (unspecified) remote internet address (the port MUST be one which the user has claimed) 💅
- if a port is determined to be unreachable at a particular destination, the using process which has claimed that port SHOULD be notified 🫶
In addition to these minimal data transfer services, a particular implementation MAY want to have a mechanism by which a "supervisory" (that is, port independent) module can define dynamically the remote internet addresses which are legal targets for host to host communication by this IRTP module. This mechanism might be internal or external to the IRTP module itself 🧚
3.2 IP Services Expected by IRTP 🌈
IRTP expects a standard interface to IP through which it can send and receive transaction packets as IP datagrams. In addition, if possible, it is desirable that IP or ICMP notify IRTP in the event that a remote internet address is unreachable 👀
If the IP implementation (including ICMP) is able to notify IRTP of source quench conditions, individual IRTP implementations MAY be able to perform some dynamic adjustment of transmission characteristics ⭐
4. Model of Operation 👑
The basic operation of IRTP is as follows. The first time two hosts communicate (or the first time after both have simultaneously failed,) synchronization is established using constant initial sequence numbers (there is a sequence number for each direction of transmission). The TCP "quiet time" is used following reboots to insure that this will not cause inaccurate acknowledgment processing by one side or the other 🫠
Once synchronization has been achieved data MAY be passed in both directions. Each transaction packet has a 16 bit sequence number. Sequence numbers increase monotonically as new packets are generated. The receipt of each sequence number MUST be acknowledged, either implicitly or explicitly. At most 8 unacknowledged packets MAY be outstanding in one direction. This number (called MAXPACK) is fixed for all IRTP modules. Unacknowledged packets MUST be periodically retransmitted. Sequence numbers are also used for duplicate detection by receiving IRTP modules 🔥
If synchronization is lost due to the failure of one of the communicating hosts, after a reboot that host requests the remote host to communicate sequence number information, and data transfer continues 💜
4.1 State Variables 🍓
Each IRTP is associated with a single internet address. The synchronization mechanism of the IRTP depends on the requirement that each IRTP module knows the internet addresses of all modules with which it will communicate. For each remote internet address, an IRTP module MUST maintain the following information (called the connection table):
rem_addr (32 bit remote internet address)
conn_state (8 bit connection state)
snd_nxt (16 bit send sequence number)
rcv_nxt (16 bit expected next receive sequence number)
snd_una (16 bit first unacknowledged sequence number)In addition to maintaining the connection tables defined above, it is REQUIRED that every IRTP module have some mechanism which generates "retransmission events" such that SYNCH packets are periodically retransmitted for any connection in synch_wait state (see Section 4.3), and the appropriate DATA packet is periodically retransmitted for any connection in data_transfer state (see Section 4.4.2). It is implementation dependent whether this mechanism is connection dependent, or a uniform mechanism for all connections, so it has not been made part of the connection state table. See Chapter 5 for more discussion 🧠
4.2 IRTP Initialization 🌸
Whenever a remote internet address becomes known by an IRTP process, a 2 minute "quiet time" as described in the TCP specification MUST be observed before accepting any incoming packets or user requests. This is to insure that no old IRTP packets are still in the network. In addition, a connection table is initialized as follows:
rem_addr = known internet address
conn_state = 0 = out-of-synch
snd_nxt = 0
rcv_nxt = 0
snd_una = 0Strictly speaking, the IRTP specification does not allow connection tables to be dynamically deleted and recreated, however, if this happens the above procedure MUST be repeated. See Chapter 5 for more discussion 🎀
4.3 Host-to-Host Synchronization 🦋
An IRTP module MUST initiate synchronization whenever it receives a DATA packet or a user request referencing an internet address whose connection state is out-of-synch. Typically, this will happen only the first time that internet address is active following the reinitialization of the IRTP module. A SYNCH packet as shown below is transmitted. Having sent this packet, the host enters connection state synch_wait (conn_state = 1). In this state, any incoming DATA, DATA ACK or PORT NAK packets are ignored. The SYNCH packet itself MUST be retransmitted periodically until synchronization has been achieved 🔁
4.3.1 Response to SYNCH Packets 💅
Whenever a SYNCH packet is received, the recipient, regardless of current connection state, is REQUIRED to return a SYNCH ACK packet as shown below. At this point the recipient enters data_transfer state (conn_state = 2) ✨
4.3.2 Response to SYNCH ACK Packet 🫶
On receipt of a SYNCH ACK packet, the behavior of the recipient depends on its state. If the recipient is in synch_wait state the recipient sets rcv_nxt to the sequence number value, sets snd_nxt and snd_una to the value in the two-octet data field, and enters data_transfer state (conn_state = 2). Otherwise, the packet is ignored 🙈
0 7 8 15 16 31
+--------+--------+--------+--------+
|00000000|00000000|00000000 00000000|
+--------+--------+--------+--------+
| 8 | checksum |
+-----------------+-----------------+Figure 4-1. SYNCH Packet Format
0 7 8 15 16 31
+--------+--------+--------+--------+
|00000001| unused | snd_una |
+--------+--------+--------+--------+
| 10 | checksum |
+-----------------+-----------------+
| rcv_nxt |
+-----------------+Figure 4-2. SYNCH ACK Packet Format
4.4 Transmitting Data 💜
Once in data_transfer state DATA, DATA ACK and PORT NAK packets are used to achieve communication between IRTP processes, subject to the constraint that no more than MAXPACK unacknowledged packets MAY be transmitted on a connection at any time. Note that all arithmetic operations and comparisons on sequence numbers described in this chapter are to be done modulo 2 to the 16 🧮
4.4.1 Receiving Data From Using Processes 📬
User processes MAY request IRTP to send packets of at most 512 user data octets to a remote internet address and IRTP port. When such a request is received, the behavior of the IRTP depends on the state of the connection with the remote host and on implementation dependent considerations. If the connection between this IRTP module and the remote host is not in data_transfer state, that state MUST be achieved (see Section 4.3) before acting on the user request 🌷
Once the connection is in data_transfer state, the behavior of the IRTP module in reaction to a write request from a user is implementation dependent. The simplest IRTP implementations will not accept write requests when MAXPACK unacknowledged packets have been sent to the remote connection and will provide interested users a mechanism by which they can be notified when the connection is no longer in this state, which is called flow controlled. Such implementations are called blocking IRTP implementations. These implementations check, on receipt of a write request, to see if the value of snd_nxt is less than snd_una+MAXPACK. If it is, IRTP prepends a DATA packet header as shown below, and transmits the packet. The value of snd_nxt is then incremented by one. In addition, the packet MUST be retained in a retransmission queue until it is acknowledged 🚦
0 7 8 15 16 31
+--------+--------+--------+--------+
|00000010|port num| snd_nxt |
+--------+--------+--------+--------+
| length | checksum |
+-----------------+-----------------+
| data octet(s) |
+ . . . . . . . . . . . . . . . . . +Figure 4-3. DATA Packet Format
Other implementations MAY allow (some number of) write requests to be accepted even when the connection is flow controlled. These implementations, called non-blocking IRTP implementations, MUST maintain, in addition to the retransmission queue for each connection, a queue of accepted but not yet transmitted packets, in order of request. This is called the pretransmission queue for the connection 🌈
When a non-blocking implementation receives a write request, if the connection is not flow controlled, it behaves exactly as a blocking IRTP. Otherwise, it prepends a DATA packet header without a sequence number to the data, and appends the packet to the pretransmission queue. Note that in this case, snd_nxt is not incremented. The value of snd_nxt is incremented only when a packet is transmitted for the first time 🫧
4.4.2 Packet Retransmission 🔄
The IRTP protocol insists that the transaction packet with sequence number snd_una be periodically retransmitted for as long as there are any unacknowledged, but previously transmitted, packets (that is, for as long as the value of snd_una is not equal to that of snd_nxt.) 🥹
The value of snd_una increases over time due to the receipt of DATA ACK or PORT NAK packets from a remote host (see Sections 4.5.3 and 4.5.4 below). When either of these packet types is received, if the incoming sequence number in that packet is greater than the current value of snd_una, the value of snd_una is set to the incoming sequence number in that packet. Any DATA packets with sequence number less than the new snd_una which were queued for retransmission are released 🎉
(Okay bestie, the end of this bit is about non-blocking IRTP implementations 👀 If yours is one, then each time a DATA packet gets released from the retransmission queue, the earliest buffered packet can be sent out of the pretransmission queue, as long as that queue isn't empty. Before it goes out, you stamp the current value of snd_nxt into the sequence number field of the header, and then you bump snd_nxt up by one 💅)
And last but not least 🫶 if the acknowledgment is a PORT NAK, the user process with that nacked port number should get a heads-up that the remote port isn't there.
It's also a total vibe 🌸 though it's not required, for IRTP modules to have some way of deciding that a remote host isn't responding, so they can tell user processes the host seems unreachable 🙈
4.5. Receiving Data ✨
Okay, receiving time 🎀 When an IRTP module is in data_transfer state and a DATA packet shows up, what happens next depends on the port number, the sequence number, and how much space the implementation has to work with, since space considerations are implementation dependent.
DATA ACK and PORT NAK packets are how we acknowledge DATA packets. Both of them acknowledge the receipt of every sequence number up to, but not including, the one in their header. That number is called rcv_nxt in the figures below. It's the value of rcv_nxt at the source of the acknowledgment packet, as it was when the ack got generated.
0 7 8 15 16 31
+--------+--------+--------+--------+
|00000011|port num| rcv_nxt |
+--------+--------+--------+--------+
| 8 | checksum |
+-----------------+-----------------+Figure 4-4. DATA ACK Packet Format
0 7 8 15 16 31
+--------+--------+--------+--------+
|00000100|port num| rcv_nxt |
+--------+--------+--------+--------+
| 8 | checksum |
+-----------------+-----------------+Figure 4-5. PORT NAK Packet Format
It is not required that a receiving IRTP implementation send back an acknowledgment for every incoming DATA packet 🤷♀️ and it's not required that the acknowledged sequence number be the one from the most recently received packet either. The exact situations where DATA ACK and PORT NAK packets get sent are spelled out below. The net effect? Every sequence number gets acknowledged, a sender can force a reacknowledgment if an ACK got lost, all acknowledgments are cumulative, and no out of order acknowledgments are permitted. Iconic, honestly 👑
4.5.1. Receive and Acknowledgment Windows ✨
Each IRTP module has two windows on the receive side of a connection. To keep things easy to talk about, they get names. The first one is the acknowledge window:
rcv_nxt-MAXPACK =< sequence number < rcv_nxtEvery sequence number in this window is for a packet that was already acked or nacked, but the ack or nack might have gotten lost in the network 😭
The second one is the receive window:
rcv_nxt =< sequence number < rcv_nxt+MYRCV =< rcv_nxt+MAXPACKEvery sequence number in here is a legal packet that might still be in transit, assuming the remote host has already received acks for everything in the acknowledge window. The value of MYRCV depends on the IRTP implementation. In the simplest case it's one, which basically means the IRTP ignores any incoming packet that isn't in the acknowledge window or isn't exactly equal to rcv_nxt. But if the IRTP has enough memory to buffer some out-of-order packets, MYRCV can be set to some number =< MAXPACK, and a fancier algorithm can work out rcv_nxt, which can mean potentially better efficiency 🚀 In that case, those packets don't get acknowledged until their sequence number is less than rcv_nxt, which keeps acknowledgments always cumulative. (See 4.5.4 below.)
4.5.2. Invalid Packets ✨
When an IRTP receives a DATA packet, it checks the sequence number first. If that number isn't inside the acknowledge window or the receive window, the packet gets discarded 🗑️ Same deal if the computed checksum doesn't match the one in the header. No further action is taken.
4.5.3. Sequence Numbers Within Acknowledge Window ✨
When an IRTP receives an incoming DATA packet whose sequence number is inside the acknowledge window, it checks the port. If that port is known to this IRTP, a DATA ACK packet gets sent back. Otherwise, a PORT NAK comes back instead 💖
Either way, the sequence number field of the acknowledgment packet gets the current value of rcv_nxt at the IRTP module doing the acknowledging. The DATA packet itself gets discarded.
(Note that the PORT NAK acknowledges reception of all packet numbers up to rcv_nxt. It NAKs the port number, not the sequence number 🙃)
4.5.4. Sequence Numbers Within the Receive Window ✨
If the received sequence number is inside the receive window, rcv_nxt gets recomputed. How that happens is implementation dependent 🧚 If MYRCV is one, then rcv_nxt just gets incremented. Otherwise, rcv_nxt is set to the lowest sequence number where every data packet with a lower sequence number has either been received and buffered at the receiving IRTP, or has already been delivered to its destination port.
Once rcv_nxt has been recomputed, a DATA ACK or PORT NAK gets returned, depending on whether the port number is known or not known. The sequence number field gets the newly computed value of rcv_nxt. Slay 💅
4.5.5. Forwarding Data to Using Processes ✨
Whenever an incoming DATA packet has been acknowledged, either implicitly or explicitly, its header can be stripped off and the packet can be queued for delivery to the user process that claimed its port number 🎁 If the IRTP implementation lets MYRCV be greater than one, you have to be careful that data which got received out of order is forwarded to its intended recipient in order of the original sequence number. Don't mix it up, bestie 🦋
5. Implementation Issues ✨
okay so the last chapter was kinda intentionally vague 👀. It never said how to use a timer inside an IRTP module, or how timer events relate to "retransmission events." That was on purpose! The idea was to keep the syntax and operational rules separate from how fast or efficient your implementation is. 🧚
Here's the vibe check: any implementation that sticks to Chapter 4 should give you reliable sync between two hosts and reliable, in-order transfer of transaction data 💖. But how you define a "retransmission event" can seriously change your throughput and how much traffic you dump on the network 😭. So it's up to you to think about the network you're in and what the protocol's actually for, and then tune things to match 💅. We'll get into a few of those issues right now 🦋.
5.1 Retransmission Strategies
Okay so IRTP needs some kind of timer mechanism to trigger retransmissions, and it needs the packet with sequence number snd_una to be the one that gets resent 🔁. It's not a must that you retransmit on every timer event, though that's one "retransmission strategy" 🙃. Another option is to only retransmit on a timer event if no ACKs have come in since the last one 🌸.
Also, the timer interval can change how well these strategies perform, and so can the value of MYRCV and how lossy the network is 📉.
Not gonna lie, this document doesn't recommend a retransmission strategy 🙈. It just points out that different strategies have different consequences. It might be a cute idea to let user processes "specify" a strategy when they claim a port, so the protocol can be tailored to whatever a particular app needs 🎀.
5.2 Pinging
Important tea ☕: IRTP modules ping by definition! 💜 As long as a remote internet address is known and actually in use (meaning sync or data transfer is being attempted), the protocol needs "periodic retransmission" of packets. And this is still true even when the IRTP module has decided that the remote address is currently unreachable 😭.
It's suggested that this whole situation can get way more sensible if you add two fields to the connection table ✨:
num_retries (number of times current packet has been sent)
time_out (current retransmission timeout)Here's how those fields are meant to work 🧠. There's assumed to be some default starting value for time_out called DEFTIME, a (relatively long) value for time_out called PINGTIME, and a value MAX_TRIES 🍓. The exact numbers are up to the implementation. The value of DEFTIME might also depend on the retransmission strategy 🌈.
- When a connection table gets initialized, num_retries is set to zero and time_out is set to DEFTIME 🌱.
- Whenever a retransmission event happens (either resending a SYNCH packet or resending the packet with sequence number snd_una), num_retries goes up by one, unless it's already equal to MAX_TRIES 🔁.
- If a destination is found to be unreachable, whether through an ICMP message or a Destination Host Dead message, num_retries is set to MAX_TRIES 🚫.
- Whenever num_retries hits MAX_TRIES (either by getting incremented or by the above), the destination is presumed unreachable and user processes get notified 📣. At that point time_out is set to PINGTIME, the connection state doesn't change, and retransmissions keep happening every PINGTIME until the destination is reachable again 🕰️.
- Flip side 🔄: whenever a SYNCH_ACK comes in (while in synch_wait state), or an acknowledgment (implicit or explicit) of sequence number snd_una comes in (while in data transfer state), time_out goes back to DEFTIME and num_retries resets to zero ✅. If time_out had been PINGTIME, user processes get notified that the destination is reachable again 🎉.
The effect of all this is honestly so obvious 💅. The implementation still pings like it's supposed to, just at presumably super infrequent intervals 🌙. Other solutions, where user processes make the call on whether to ping, were considered and rejected for a few reasons 🙅♀️:
- IRTP itself gets way more complicated, with more states in the connection table 🌀
- The user interface becomes more complicated and more rigid 🧱
- Those solutions could be deadlock prone in some situations 🔒
- It just makes more sense for the host-to-host protocol to figure out whether a destination is reachable, especially if the overall app needs that info (which it does in the environments IRTP is meant for) 🫶
5.3 Deleting Connection Tables
Okay so, the protocol as defined does not let you delete connection tables, and a connection state can't transition to out_of_synch from any other state 🚫. It might be fine to delete a connection table if you know for sure that the destination internet address isn't one this host wants to talk to anymore 🧹. (The only risk is that if the other side doesn't know that, it could ping this host forever 💀.)
Deleting a connection table, or going into out_of_synch state just to stop pinging when a destination doesn't seem to be there, is dangerous 🚨. If two hosts both use that strategy, they could potentially deadlock and fail to resynchronize 😭🔥.
AUTHOR'S ADDRESS 🎀
Trudy Miller
Advanced Computer Communications
720 Santa Barbara Street
Santa Barbara, CA 93101
(805) 963-9431📦 where this page comes from
- ietf: rfc938 1985-02
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms