Sender progress

[luc1an]

Hi again!
Knowing that the sender is dividing the data to be sent in chunks of bufferSize kb, i would like to provide some progress to the sender by handling a sender event, in the same way the receiver is handling NORM_RX_OBJECT_UPDATED. Is there something that i can catch ?

[bebopagogo]

Are you using the NORM_OBJECT_DATA mode? There are a couple of sender events that can be leveraged, but are issued at object boundaries versus more granular, incremental updates on sender progress. Also the TX_QUEUE_VACANCY / EMPTY is another indication but for "objects" transfers is at the object boundary. For something more granular, an API could be added to poll some indices that NORM keeps under the hood for where it is at in the progression of sending an object. Basically for a given NormObjectHandle, a call could be added to fetch the "next pending block/segment" index information and that could be call periodically by the application to provide a progress indicator.

Oh (thank you Google AI), it looks like the NormObjectGetBytesPending() call does this .... " It returns the number of bytes that remain to be sent for that object" ... so if you take objectSize minus that value it gives an idea where the sender is at on transmit progress for the given object.

[luc1an]

Yes, i am using NORM_OBJECT_DATA mode. However it's not critical to my app, but it's good to know that it's possible. The data being sent is a couple of hundred bytes usually.

[bebopagogo]

For small messages the NORM_OBJECT_STREAM has some benefits depending on your use case. The packet erasure coding capability of NORM is "striped" across multiple segments with NORM_OBJECT_STREAM where for NORM_OBJECT_FILE/DATA the coding is constrained to within the "object". So, for small objects (e.g., a single message), the extra benefits that packet erasure coding can provide to the ARQ for multicast comms is limited. However, currently NORM_OBJECT_STREAM always enforces in-order delivery of the stream data to the receiver(s), so if lower latency is more important than in-order delivery, NORM_OBJECT_DATA can be better. I plan to augment the API and code base to enable out-of-order delivery of message data as an option so the best of both worlds is available, but not going to get to that very quickly

[luc1an]

In-order delivery is not important. So thanks for the clarification. In my case latency is given not by code by the very low speed networks that we'll be using. Btw, i haven't checked yet with a tool like Wireshark but can you share some information regarding the bandwidth consumed on top of the package size?