Segmentation for Outgoing Messages
nickngsr opened this issue · 6 comments
Node Version: 10.15.3
Node BACstack Version: 0.0.1-beta13 (actually using clone of master, but same in current npm release)
- Bug Report
- Feature Request
- Question
Note: Make sure you have read the FAQs
before logging this issue.
Feature Request / Question
I could be wrong here but I don't think segmentation in responses works, or perhaps we have to implement in our own logic.
Would it be possible to implement segmentation in responses, in particular readMultiple response or a writeMultiple request.
Unfortunately I don't know enough about the bacnet protocol myself to implement (i.e. segmented packet structure), however if you point me to somewhere that clearly lays out the packet structure I could potentially submit a pull request.
I should probably state at the moment if the response to a readPropertyMultiple is very long, node throws a buffer size error (caused by the hard coded 1482 buffer size from getMaxPayload() ), is this an oversight or does segmentation need to be implemented for outgoing things?
I know its not the solution you're looking for but one can batch the RPMs & WPMs to keep it under the MTU size.
UDP has a physical MTU limit and to get around this, UDP supports fragmentation. However, I do not believe bacnet supports / fully utilizes this and hence they use their own segmentation layer. Segmentation for responses does work however segmentation for requests as you noted does not. Will have to check the spec to see if its supported for requests. Part of the trick is the spec is not open.
Yes indeed, my aim is to be able to respond to a 'readPropertyMultiple' request from another device with a payload of any size (I'm trying to be a bacnet client device rather than the normal master)
I too have discovered this issue, my device has a huge object_list that exceeds the hard coded buffer MTU limit of 1482.
Did you manage to find a solution or workaround for the lack of segmentation on the readPropertyMultiple response?
Or how would I "batch the RPMs & WPMs to keep it under the MTU size."
I haven't had time to look in to this and just went with the easy solution of just not supporting readPropertyMultiple for my use case. There seems to be a far more active fork here, it might be worthwhile creating an issue there and seeing where that goes.
Cheers Mate