Closed sappenin closed 5 years ago
Also, see test coverage in AsnStreamDataFrameCodecTest
Thinking more about this, maybe we just write some test coverage in SenderReceiverTest
to exercise this use-case and make sure we like the error messaging. I think that most connectors will reject ILPv4 packets with more than 32k of data, so it's unclear to me if we need to do anything special here, but I think it depends on what the errors look like coming from the STREAM sender, etc.
Upon further discussion this probably isn't a case that we can handle in Quilt very effectively as the packet size is an implementation detail of a connector and should really only be reinforced by the server and not the client. If the client were to enforce this limit as a precondition it could create a scenario in the future where, if the server were to increase the packet size it could handle beyond 32kb, there could be incompatibility forwarding a payload due to a client restricting the size where the server doesn't actually care.
See ASN.1 OER definition of the ILPv4 packet's data field here: https://github.com/interledger/rfcs/blob/master/asn1/InterledgerProtocol.asn#L30
One way to guard against this is just the Immutables check in the InterledgerPacket.java.
However, we might consider adding logic in the stream-core code possibly, although since this is a guard at the ILPv4 packet, we probably should just leave it there.