[PD] ugly "already connected" errors
itsnotfair9 at gmail.com
Fri Jan 25 15:48:41 CET 2019
Thanks for looking into this.
The listener is an app called Lemur which receives and sends OSC messages . I don’t know too much about the workings of this app though...
> Am 25.01.2019 um 15:35 schrieb Roman Haefeli <reduzent at gmail.com>:
> What you found, challenged my understanding of UDP and it seems,
> depending on implementation, the sender socket is in some cases
> notified about the termination of the receiving socket.
> When I connect [netsend -u] to a small python script that opens a
> listening socket, i can kill the script and start it again and [netsend
> -u] can still send packets. When I connect to 'nc -v -u -l -p 11579'
> instead, [netsend -b] can send packets only as long as the process is
> running. When I kill nc and start it again, no messages reach their
> destination anymore. I have to 'disconnect' and 'connect'.
> So what kind of software is opening the listening socket on the phone?
>> On Fri, 2019-01-25 at 15:14 +0100, Roman Haefeli wrote:
>>> On Fri, 2019-01-25 at 15:01 +0100, michael strohmann wrote:
>>> thanks for the answer!
>>> in order to show that there is a connection betwenn the app to pd i
>>> [metro 1000]
>>> [oscformat BlinkingButton/value]
>>> [list prepend send]
>>> [list trim]
>>>> [t b]
>>>> [disconnect, connect 192.168.178.189 8000(
>>> [netsend -u -b]
>>> now everytime the phone is not available i get:
>>> recv: Connection refused (111)
>>> netsend: Bad file descriptor (9)
>>> warning: 35 removed from poll list but not found
>>> if i dont disconnect before sending i get the “already connected”
>>> and if i only connect once and leave the pd side connected, no
>>> messages are received on the phone once it leaves the wlan.
>>> messages sent from the phone are almost always received.
>>> in any case it get a console message, either “connecting to port
>>> 8000” or “already connected”
>>> i am just concerned because my patch crashes or freezes or create
>>> glitchy digital artefacts from time to time, and since it is a 24/7
>>> audio installation i would like it to work.
>>> how to find these bugs...
>> Oh, I see. That's much messier than I thought. I always believed an
>> socket stays open regardless of the presence of the other end. But
>> seems to be not fully true. I'm not sure what's going on but it looks
>> like the OS closes the socket without [netsend] actually noticing
>> I would try what Antoine suggested and send a 'disconnect' each time
>> before you connect again. There should be no harm in 'disconnect'ing
>> and 'connect'ing many times.
> Pd-list at lists.iem.at mailing list
> UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
More information about the Pd-list