fh1ch / node-bacstack

A BACnet protocol stack written in pure JavaScript
MIT License
174 stars 98 forks source link

Segmentation for Outgoing Messages #136

Open nickngsr opened 5 years ago

nickngsr commented 5 years ago

Node Version: 10.15.3

Node BACstack Version: 0.0.1-beta13 (actually using clone of master, but same in current npm release)

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 commented 5 years ago

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?

NateZimmer commented 5 years ago

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.

nickngsr commented 5 years ago

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)

albybott commented 4 years ago

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

nickngsr commented 4 years ago

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.

albybott commented 4 years ago

Cheers Mate