open-dis/open-dis-java

BehaviorProducerUDP throws buffer underflow exception when variable datum is greater than MTU

wviers opened this issue · 4 comments

While the answer to this issue might be well duh...

I am working with simulation software that I don't have control over that is regularly sending Data PDUs that contain variable datums greater in the realm of ~2000 bytes.This is causing a buffer underflow exception to originate from \edu\nps\moves\net\BehaviorProducerUDP.java, due to it’s hardcoded buffer size on the ethernet MTU constant in \edu\nps\moves\net\BehaviorWriterIF.

Assuming I am not wildly off base and misunderstanding the situation would it be better for open-dis to allow the user to configure that recieve buffer size if the user is operating in a network that supports UDP fragmentation? The DIS standard itself says the max size of a PDU is 8K bytes (again) if I am not mistaken. Simply changing that constant to a larger MTU size in the open-dis source alleviates my issues but I don't want to deviate.

Thank-you for the report @wviers . You're right, that is too small and will causes issues.

The DIS 2012 spec says the max size is 8192 so we should use that value. Would you like to submit a PR for the change?

image

I would be happy too but it will take a little time because I sadly have to get some approvals to push code written on company dime out into the world first...even just a comment and constant value change.

Ok that's understandable. I can wait while you get it sorted.

The class mentioned here, BehaviorProducerUDP was deprecated and then recently removed in #126 .

Instead of using that class, I'd recommended trying the DisConnection class which sets a MAX_PDU_SIZE = 16384;

https://github.com/open-dis/open-dis-java/blob/master/src/main/java/edu/nps/moves/disutil/DisConnection.java#L21

There was a specific reason the constant was set to double the size of the spec...admittedly I've forgotten why. If it comes to me I'll circle back and add a comment to the constant in the code.

@wviers I'm going to close this issue. If it doesn't address your issue feel free to leave a comment and reopen the issue though.