Closed joproulx closed 2 years ago
Hi @joproulx, thanks for sharing details with your issue. So far I only had segmentation in responses but BACnet supports also segmentation in requests, so your use case if valid.
Does this imply that segmentation on transmit is not supported? Or there is a different way to achieve this, that I don't see?
Unfortunately, based on my quick review, this codebase is not prepared to send requests in more than one frame. There are fragments that seem prepared for that:
but BacnetPduTypes.SEGMENTED_MESSAGE
is never set in case of sending confirmed service request.
If segmentation on transmit is not supported, what would be the best way to determine that my request is too big?
First of all, as a workaround, I suggest you split your request into two or more (asking for a subset of all the properties you need) and then combine the responses (I guess you know this but just in case anyone reading this doesn't).
I think currently you won't know your request is too big unless you try to send it (and fix the silent error).
If I were to send a PR to help fix the silent error, what would you suggest? Log an error in that case? Or let the exception bubble up?
Originally this codebase was in C/C++ and later was ported to C#. That's why you don't get exceptions in most places but rather result codes or boolean results. As a C# developer however, I would expect an exception to be thrown when I try to send something that can't be sent. I don't know however where would be the best place to determine it - you can suggest something.
Ok thanks for the explanation @gralin. I split the ReadPropertyMultipleRequest
as suggested and it works fine.
Originally this codebase was in C/C++ and later was ported to C#. That's why you don't get exceptions in most places but rather result codes or boolean results. As a C# developer however, I would expect an exception to be thrown when I try to send something that can't be sent. I don't know however where would be the best place to determine it - you can suggest something.
I see. your point. I would suggest to just avoid swallowing the exception and let it bubble up.
But again, this is not a critical issue since it doesn't really break any functionality. Thanks again for your answer!
Sure, I agree, I would only wrap the original exception with something more meaningful than OutOfRangeException
, so that it's clear that you are trying to send too much data and since segmentation of requests is not implemented, this has failed. Feel free to submit a PR if you want to improve the codebase.
Description:
I am trying to send a big ReadPropertyMultiple request through UDP and and looking at Wireshark, I can see that the request never gets to the network.
Investigation:
There is an ArgumentOutOfRangeException thrown when sending data through the UDP socket (![image](https://user-images.githubusercontent.com/1434190/185936216-687b7c16-0e18-4701-ae45-a5e9e744a525.png)
BacnetIpUdpProtocolTransport.Send()
). As you can see, the data length (1693) is greater than the max ADPU which is 1496. When an exception is thrown there, we return 0 without logging any errors.In![image](https://user-images.githubusercontent.com/1434190/185936383-a30f7d04-46e9-438d-bb48-e9599d428021.png)
BacnetAsyncResult.Resend()
, the caller of the Send() method receives0
as a result and just return normally without any error nor logs.Questions:
Thanks for the great library by the way. Really useful!