queries from the spawned session take 10 sec to complete

[EastEriq]

In the master:

>> S=obs.util.SpawnedMatlab;
>> S.spawn
>> S.connect;
>> tic; S.Messenger.areYouThere, toc

ans =

  logical

   1

Elapsed time is 0.142787 seconds.
>> tic; S.Responder.areYouThere, toc

ans =

  logical

   1

Elapsed time is 0.061294 seconds.

In the slave instead

>> tic; MasterMessenger.areYouThere, toc

ans =

  logical

   1

Elapsed time is 10.016357 seconds.
>> tic; MasterResponder.areYouThere, toc

ans =

  logical

   1

Elapsed time is 10.015797 seconds.

what did I do to cause this?

[EastEriq]

This is because in https://github.com/EastEriq/LAST_Messaging/blob/4ca037339dcff62f87b01f688c30e3a056a6812a/%2Bobs/%2Butil/%40Messenger/query.m#L66 I safecheck that the datagram just received comes from the port expected. Only, this is a relic of when the Messengers were 1:1, and I was using fixed local and remote ports for them, in mutual correspondence. Now I resolved not to update Msng.DestinationPort but only Msng.StreamResource.RemotePort whenever a message requesting reply is received. This may have been in .executeCommandAndReply() around commit 9ccdf0179a or earlier. The idea sort of was to keep Msng.DestinationPort (ditto .DestinationHost) as fixed, reminescent of the default partner of the Messenger.

The fix is thus easy. I note that the whole business of the gledmagicwater branch was so successful despite this, and this may be an indication that in it I completely removed queries backfiring from the Slaves to the Master. In fact I became aware of the bug only lately, noting that in certain cases commands to the Slaves not semicoloned, which cause Unit output, took multiple of 10 seconds to complete. This is e.g. because the screen output of Unit includes Unit.Temperature, which .classCommands Unit.PowerSwitch{:}, which is a remote class in the slave Unit...

[EastEriq]

For completeness, I also let now SpawnedMatlab.connect pass the actual local Responder port when constructing MasterResponder in the slave. This is for definiteness, but doesn't really help with slave queries like Unit.Temperature if in the meantime the same MasterResponder is queried by something else (Superunit Monitor e.g.). Mixup of replies - requests will result, and we're not treating it (treatment would imply enqueueing incoming datagrams and treating them according to type and provenance)