LTP session state leak with non-checkpoint data timeout

[BrianSipos]

The current LTP engine and session keeping logic does not provide a mechanism for a session to timeout except for red data checkpoint (and EORP, EOB) reports. Unfortunately, the LTP spec (both IETF RFC 5326 and CCSDS 734.1-B-1) are silent about correct engine behavior in the case of a non-checkpoint timeout situation.

I have two simple ways to produce this problem:

1. Send an LTP segment type 0 (red non-checkpoint) with a new Session ID and arbitrary data.
2. Send an LTP segment type 4 (green non-EOB) with a new Session ID and arbitrary data.

In both cases the LTP engine will establish new session state and wait for all red data (with associated reports and their timeouts) or all green data. But if these never arrive, for whatever reason, the LTP engine will persist this session state indefinitely and also never give an indication to the application that this has occurred.

It would be very helpful to the application to have some kind of "no further data received for the session" cancelation from the receiver, with its associated API callbacks for RX session cancellation. The LTP specs don't reserve a cancel reason for this, but the existing code 0 "Client service canceled session" could be used. I could implement this as a client-service-level timeout for green segments not for red segments, as the API doesn't indicate individual red segments to the client. This timeout would be something like "maximum time between receiving any segments associated with a session before cancelling" with a timer reset any time any segment is received for a given RX Session ID.

[BrianSipos]

Because this is a housekeeping timeout, it could be considerably larger than the normal round-trip-delay computed timeouts so it wouldn't conflict with having a simple logic that resets any time a segment is received for an RX session. The point is to know when to give up on an RX session and discard unneeded state.

[briantomko]

@BrianSipos I have this issue resolved on another branch. Will try to push later this week. I have a housekeeping timer which runs once a second and looks for any rx session which hasn't had any activity for at least: (round_trip_time) * (1 + maxRetriesPerSerialNumber) and then it will

1. calls the receptionSessionCancelledCallbackwith reason code USER_CANCELLED
2. sends the cancel segment to sender
3. deletes the session

I have a unit test for this with fully green data where I never send the GREENDATA_ENDOFBLOCK. It also appears to be working with red data in regular testing, I just don't have a unit test for that.

[briantomko]

@BrianSipos This issue has been resolved with commit b5e08cc

Also, please note that there is now a slight api change to AddLtpUdpEnginewith one additional (last) experimental parameter: param maxUdpPacketsToSendPerSystemCall: The max number of udp packets to send per system call. If 1 is used, then the receiving udp socket is used to send udp packets from the specified bound port that it is on and one boost::asio:::async_send_to is called per one udp packet to send (original behavior). If more than 1 is used, a dedicated sender udp socket is created and bound to a random ephemeral port, the socket is then permanently "UDP connected" to the remoteHostname:remotePort, and packets will be sent using this socket's sendmmsg on POSIX or LPFN_TRANSMITPACKETS on Windows. In making this change, a few memory issues were discovered and fixed, where (especially with green data and possibly red data) could get deleted before a socket completed sending the data.