I was hoping that there was a way for a plugin to know what DAW track it's on, similar to the $1 clone ID, but I was told on the plugdata discord that the plugin specs don't support that. Then I thought maybe I could have an ID service running and have each plugin get its ID when it's created, but that doesn't seem to work. I think it has something to do with TCP/IP that I don't understand. Here's the instanceIDService:
And here's the instance:
If I just clone the instance 5 times and run everything outside the DAW, the instanceIDService appears to get 5 ID requests but every instance receives only the first response.

If in REAPER I create 6 tracks, each with a plugdata VST that has loaded "instance.pd", it appears that each instance hears the reply to every subsequent instance ID query. Here's the instance on track 1:

Finally, when I close REAPER, it looks like TCP/IP connections are still open, i.e. [disconnect( was ignored, which is consistent with the previous observation..

Can you help me understand what is going on?
instanceIDService.zip

@jameslo No time to look into why..... although nothing differentiates the instances as far as I can see.... and maybe you need a [list trim] somewhere...
Could you use separate ports ... 8001 8002 8003....... etc. for the tracks?
David.

I'd guess that it is related to timing issues inside plugins, (with netsend and loadbang that don't follow the same deterministic order of execution.... something like that) .
I tried your server/client approach with pdlink instead of netsend/ netreceive, using [spigot] instead of [disconnect( to stop receiving messages from server, but I got the same kind of issues :

If your goal is to get an unique ID for each instance, did you try [random <big_number>] ?
It seems the random number changes on loadbang with every instance :

@whale-av "nothing differentiates the instances"--that's the point. If I've used the same plugin on a huge number of tracks but want to modify their behavior slightly per track, there's a lot of configuring to do. If I have to make each instance go to a different port, then that's the same amount of manual work as the configuration I'm trying to avoid. I'm trying to make something like the clone ID $1.

This morning I'm remembering that my code works the first time, as I am adding tracks or plugin instances one at a time, so maybe I just have to save that ID and disable getID for subsequent runs, i.e. when REAPER reloads the project, I dunno.

@jyg RE [random], yeah, I thought about that, but my original goal was to know what track I'm on, and I was confident that REAPER loads and initializes each plugin in the same order every time (that appears to be true). A random number would help distinguish the instances (most of the time) but couldn't be used to deduce the track.

I think my scheme is failing because I'm assuming that several netsends can connect to a single netreceive and have a private connection. That's true over the internet, right? But both the standalone and REAPER behaviors suggest that all instances share the same connection.

@jameslo Before [clone] we would have used a counter to generate instances by dynamic patching.
It's a fairly trivial thing to do..... incrementing the port number or a variable name for each iteration......
I admit to little experience with VST and none with plugdata.
Interesting conundrum for airport waiting during the next few days.

I wonder if you are running into TIME_WAIT issues where you disconnect/reconnect repeatedly to the same port.
If you are on windows then try tcpview.exe from the Microsoft sysinternals suite to get a better idea of any tcp issues.
David.

@whale-av I think this next test shows that TCP/IP connections are indeed shared when running Pd standalone:

I never requested getID from the right netsend but I got an answer anyway. Note that TCPView shows the right netsend's connection still established as expected. So [netsend/receive] shares data, but not control?

Now look at TCPView when I run the REAPER/plugdata VST test and wait a bit:

All 6 connections from each of the 6 plugins are still established! What you can't see is that for a while, TCPView was attributing all 6 of those connections to REAPER, but they one by one switched to pd.com. So strange.

But look at the local/remote address and port. See how there's a unique remote port for each established connection? My understanding was/is that these 4 identifiers taken together define the connection, which in this case should be unique, so I shouldn't be getting crosstalk.

@jameslo This has my head spinning...... https://stackoverflow.com/questions/3329641/how-do-multiple-clients-connect-simultaneously-to-one-port-say-80-on-a-server
.... but might contain the answer.
It suggests, as the IP's are the same and the PIDs the same they are sharing the connection.

However, in the second TCPview screenshot the Reaper ports are only listening and have sent no data.
But Pd has numerous (high) ports open and sending and receiving data..... presumably one for each instance.
So Pd is talking to itself, and I suppose that is in the nature of a VST... which only hooks into the host data and does not "run" within it?
I have no idea if that is a true statement, and I have to give up as I have an early flight.

I thought I had mastered networking but...... https://superuser.com/questions/949428/whats-the-difference-between-127-0-0-1-and-0-0-0-0
X David.

I tested with instances running on 2 different machines, and I left the connections open. The "backwards" response to the second instance was also sent to the first instance! So this must be the expected behavior of "backwards", can anyone confirm? i.e. it sends a message back to all connected clients.

I also noticed that [netreceive -f 8000] adds a right-most outlet that lists the originating IP address and port of the incoming connection. It reports the same info as TCPView. If instead of using the "backwards" feature, I try making a netsend connection to the originating IP address and port, the connection is refused. So "backwards" is not the same thing (which is probably obvious to anyone who knows networking).

I see that you can tell the server what port to use for replies if you use UDP, but if the instance could know which ports in a pool of ports were available, then it could derive its own ordinal ID, e.g. if 5 of the ports are already taken, then we must be Number Six (but we would still not know who is Number One).

I added a toggle to show whether [netsend] thinks the connection is open and a numberbox to show how many connections [netreceive] thinks are open, and in the REAPER plugin test, each instance thinks it's open even when nothing is listening on localhost:8000, and there is no error message in any plugdata console. Even weirder, each instance thinks it's closed after the [disconnect( is issued, even though both TCPView and instanceIDService report 6 open connections. Is this a plugdata issue? What other tests would you perform to investigate further? The standalone tests all behave similarly in standalone plugdata.

Finally, I have a theory for why the plugin behavior differs from the standalone behavior. In the latter case, the instances are instantiated so quickly that only the first backward message gets broadcast before all instances disconnect. But REAPER has a lot more work to do, initializing each track, loading plugdata and then restoring plugdata to its saved state, so there's more time between instantiations. The fact that the connections aren't being closed explains why the first instance sees all 6 replies, the second sees the last five, ..., and the last only sees the last reply. So if I make each instance ignore all but the first reply, I get the result I wanted! But in my working life as a programmer, I and my colleagues would've pejoratively called that a hack because it depends on REAPER's timing, which is unspecified, so I'm not really celebrating. For instance, if I run the instanceIDService as the first VST plugin, things are broken.

I'm also going to go out on a limb and say that I think [netreceive] is under-featured. In a Python example I found, they create a socket, bind it to a port, and start it listening. When a client connects, the socket returns a connection from/to which you get/put data. [netreceive] seems to be acting as both the socket as well as the aggregate of all the connections. That's not right! (Or is it?)
test instance ID.zip

Maybe you can use one [netreceive] to serve available ports and others in [clone].

• The instance first ask the fixed port for a dynamic port number, then close the connection (and don't take care anymore of its output so if the disconnection is delayed and the server still push something, it's discarded)
• The instance open then another connection with the given dynamic port.

At server side the [netreceive]s get their ports numbers from the $1 which contain the clone instance number. You can start the port minimal number where you want with the -s argument of [clone].
The callback is sent back to the main patch throw the clone instance outlet.