Currently every RIFT-Python node always summarizes its entire TIE database in a single TIDE packet.
If the TIE database is very large (contains many TIEs) then the TIDE packet can get very large.
The one and only TIDE packet is always sent in a single UDP packet. If the UDP packet is larger than the interface MTU, UDP fragmentation will split it into multiple IP packets which the receiver UDP will reassemble.
Consider enhancing RIFT-Python to spread the TIE database summary over multiple TIDE packets. The RIFT TIDE packet has a range field for exactly this purpose.
This potentially can avoid UDP fragmentation, which could potentially be a good thing.
The downside is that it brings in a lot of extra complexity, and at this point it is not clear to me that the extra complexity is worth it (since RIFT-Python cannot support huge networks in the first place for completely other reasons, or maybe for multiple reasons including this one).
Currently every RIFT-Python node always summarizes its entire TIE database in a single TIDE packet.
If the TIE database is very large (contains many TIEs) then the TIDE packet can get very large.
The one and only TIDE packet is always sent in a single UDP packet. If the UDP packet is larger than the interface MTU, UDP fragmentation will split it into multiple IP packets which the receiver UDP will reassemble.
Consider enhancing RIFT-Python to spread the TIE database summary over multiple TIDE packets. The RIFT TIDE packet has a range field for exactly this purpose.
This potentially can avoid UDP fragmentation, which could potentially be a good thing.
The downside is that it brings in a lot of extra complexity, and at this point it is not clear to me that the extra complexity is worth it (since RIFT-Python cannot support huge networks in the first place for completely other reasons, or maybe for multiple reasons including this one).