[PD-dev] [ pure-data-Bugs-1891178 ] netsend/netreceive sometimes drop data

SourceForge.net noreply at sourceforge.net
Sun Feb 17 17:11:24 CET 2008

Bugs item #1891178, was opened at 2008-02-11 15:45
Message generated for change (Comment added) made by sistisette
You can respond by visiting: 

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: puredata
Group: v0.40.1
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
>Summary: netsend/netreceive sometimes drop data

Initial Comment:
If you send a great enough number of messages throught a netsend immediately after the connection is established (for example triggered by the 1 output of netsend), the first messages are lost (and no error message issued). Netreceive receives some corrupted data, and then the last N messages sent.

The attached patch illustrates the problem.

Click on the [connect ...( message box

On PD output window the following should appear:

DATA: bla bla 1
DATA: bla bla 2
DATA: bla bla 3
DATA: bla bla 1000

The following output appears:
DATA: 53
DATA: bla bla 954
DATA: bla bla 955
DATA: bla bla 1000


Note that if you later click the [bng], all works as expected, i.e. no message is lost: message loss only seems to happen when too many messages are sent immediately after connection.


>Comment By: Matteo Sisti Sette (sistisette)
Date: 2008-02-17 17:11

Logged In: YES 
Originator: YES

fixed in 0.41-2


Comment By: Nobody/Anonymous (nobody)
Date: 2008-02-13 12:54

Logged In: NO 

This DOESN'T ONLY happen when the burst of messages is sent immediately
after connection.

I have experienced message loss even sending a big burst of messages to a
netsend that has been connected for a long time.

I may send a burst of M messages and loose messages K through N with
In this case message N+1 is corrupted (its last part is received).

Also, it seems that the burst doesn't need to be sent in 0 logical time to
reproduce the bug. It seems it is sufficient to send enough messages in
enough little time.


You can respond by visiting: 

More information about the Pd-dev mailing list