Christian Grothoff <[email protected]> writes: > Yes, in the worst-case they are buffered in the _client_ processes' > memory. You can check the MQ API (length, send callback) for ways to > find out if your messages are piling up (or at least have left your > process), so you DO have a way to do proper flow control.
Great :) > Are you re-using the same envelope? Did you check for memory corruption? > Is this just between your service and your client? Where is CADET here? I made sure to use a new envelope each time. In fact, the real implementation is a dedicated function that does some basic checking (e.g. make sure the pointer to the data is not NULL) before sending the message. I tried calling it both inside a normal for loop and also as "scheduled tasks" using `GNUNET_SCHEDULER_add_now' after each message is sent (of course tasks were added only if there were more segments), but to no avail: the service gets only the first segment. CADET right now is not implemented, but what I'd like to do is to use the same segmentation mechanism. Since both CADET and the client-service communication use the same MQ API, I assume I can do it just fine once I solve this problem. Thanks, A.V. P.S. I had originally sent this to help-gnunet, but in the last reply I managed to mess things up and accidentally sent it to gnunet-developers. Though according to the description of help-gnunet, discussing this issue might be more appropriate to this list. Anyway, sorry about sending mails to two different places. _______________________________________________ GNUnet-developers mailing list [email protected] https://lists.gnu.org/mailman/listinfo/gnunet-developers
