#1

Hello,

I’m working on some puredata objects for use with serialosc, to make finding, connecting to and communicating with grids and arcs easier. Right now I’m working on using serialosc’s device add/remove notification feature to enable seamless reconnection to devices which get unplugged, and I’ve come across a couple of odd things.

Firstly, there seems to be a mistake in the serialosc documentation about the /serialosc/add and /serialosc/remove messages which are sent to my application on device status changes. The documentation says that the data sent is a single string, the ID of the device. When I actually get the messages however, the data is exactly the same as I get from /serialosc/device, ssi-formatted id, name, portnumber. If anything this is more useful than just the ID, but if this is intended behaviour then the documentation needs to be corrected.

Secondly, it seems as though sending multiple identical notification requests to /serialosc/notify results in that number of identical notifications being sent when a device is dis/connected. Seeing as there is no (documented) way to cancel a request for a given (hostname, portnumber) pair, I would expect calls to /serialosc/notify to be idempotent, where multiple notification requests collapse into one until it’s cleared by a notification being sent.

The specific problem this is causing for me is that when I create a [monome grid] object, it requests a notification. If I then delete the [monome] object and create another one, it’s usually assigned the same port number as the previous one was, but also requests a notification. Then, when a device is added, it gets two notifications (or more if I’ve created the object several times).

It’s difficult to filter out these multiple notifications on the client side as that would require maintaining a list of all the device IDs seen by an object and their current status, which a) is annoyingly difficult to do in puredata and b) seems more like it’s serialosc’s job anyway.

So am I right in thinking that this is a serialosc bug or at least unintended behaviour which could be improved by making notification requests idempotent, or is this a necessary behaviour which I need to work around on the client side?

#2

who is the best person to ping about this? @tehn?

#3

hello! sorry i missed this one.

in the past i’ve likewise noticed some possibly tricky behavior in the notifications.

if i recall correctly, i thought it was required to resend /serialosc/notify for each new event— ie, notify only asks for one event (the next), so serialosc would stop sending if it didn’t get a re-request. obviously what you’re seeing contradicts this, so i’m wondering when this changed, or if it was ever implemented properly.

you mentioned objects— are you working in max?

#4

Thanks for the reply! I’m working in puredata.

In my case, serialosc is correctly sending one notification per request, the problem is that when I create a Pd object containing a [netrecv] UDP server for getting data from serialosc, it gets assigned the first free port number after an arbitrary search start number (e.g. 10000).
On creation, my object requests a single status notification from serialosc. If I delete this object, then create another one, it will most likely get assigned the same port number as before, for which there’s already an outstanding notification request. However, my object has no way of knowing this, and sends a second notification request for the same (hostname, port) pair as the previous one. The problem is that these notification requests stack, and so if I’ve created and deleted a few of these objects, on each (dis)connect event, serialosc will send them many identical notifications.

There are a few ways I could work around this, such as trying to guarantee that each [netrecv] server ever created gets a unique port number, but I think serialosc’s behaviour is counter-intuitive, and that it would make sense and be more useful to treat calls to /serialosc/notify as being idempotent for each (hostname, port) pair i.e. no matter how many /serialosc/notify localhost 10000 requests get sent, on the next (dis)connect event, serialosc sends a single notification message to localhost:10000.

Does that make a bit more sense?

#5

it certainly does make more sense.

i think this is the relevant part that needs changing (should check if the host/port exist already):

i’ll try to look at this by the end of the week

#6

That sounds great, thanks a lot! If I knew anything at all about writing C I’d have a go at implementing it myself… unfortunately not.