node-bacstack icon indicating copy to clipboard operation
node-bacstack copied to clipboard

Segmentation for Outgoing Messages

Open nickngsr opened this issue 6 years ago • 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
  • [x] 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.

nickngsr avatar May 27 '19 18:05 nickngsr

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?

nickngsr avatar May 27 '19 20:05 nickngsr

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.

NateZimmer avatar May 27 '19 21:05 NateZimmer

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)

nickngsr avatar May 27 '19 21:05 nickngsr

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."

albybott avatar Aug 17 '20 23:08 albybott

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.

nickngsr avatar Aug 17 '20 23:08 nickngsr

Cheers Mate

albybott avatar Aug 17 '20 23:08 albybott