Windows Version
25H2 26200.8246
Service Installation Method
Other (please indicate below)
SDK version, if appropriate
1.0.17-rc.4.25
Location
Other or Unsure (please indicate in additional notes section below)
Type of bug
Application not working as expected
Steps to reproduce
I've been testing the network MIDI preview with phones and ESP32s on wireless networks. In such environments it is pretty much inevitable that at some point a UDP packet will be dropped or delivered out of sequence. The MIDI Server detects that fine and starts issueing retransmit requests according to the specs. It does however not honour that the remote side may not be able to resend the requested data, ignores NAK - 'not supported' replies, keeps repeating the retransmit request and in consequence effectively breaks the connection as no subsequent data is accepted anymore. This seems to be violating the specs:
7.2.3
If a Device does not implement the Retransmit mechanism, it shall reply to the Retransmit Request Command
with a NAK Command with reason 0x01 (Command not supported). See Section 6.15. The remote Device should
not send Retransmit Request Commands after that.
I tried sending 'session reset' commands after the NAK reply, but those are ignored as well.
Expected behavior
I would expect the server to accept that some data unfortunately has been lost and just keep going.
Additional notes
MIDI Service installation is fully 'retail' as delivered and activated by Windows Update. No hotfixes have been installed manually.
Some more observations with the Network MIDI preview not directly related to the above (Some of these may just reflect the preview / alpha state):
On machines with multiple network interfaces multiple host sessions will be announced, but they are indistinguishable by their default names (all called 'Windows COMPUTERNAME'). Invitations on the WiFi interface are occassionally answered on ethernet and vice versa.
When inviting a remote session the server uses the client's endpoint name as its endpoint name. That makes sense from the server's point of view, but can be a bit confusing when dumping data on the client side or going through Wireshark captures. As with the hostnames above some prefix or marker would be welcome.
I don't think that letting the server pick a random port number for host sessions is a good idea. That will break all automatic setup and reconnect scenarios. The optional 'fixed' port number entry in the 'advanced' settings does not seem to work at the time being, but I would anyway suggest to make 'random port' the advanced option or drop it entirely.
Repeatedly connecting and disconnecting remote sessions may work fine, but often a 'Disconnect' does nothing (no BYE is sent) and usually the service crashes a couple of seconds later then.
Windows Version
25H2 26200.8246
Service Installation Method
Other (please indicate below)
SDK version, if appropriate
1.0.17-rc.4.25
Location
Other or Unsure (please indicate in additional notes section below)
Type of bug
Application not working as expected
Steps to reproduce
I've been testing the network MIDI preview with phones and ESP32s on wireless networks. In such environments it is pretty much inevitable that at some point a UDP packet will be dropped or delivered out of sequence. The MIDI Server detects that fine and starts issueing retransmit requests according to the specs. It does however not honour that the remote side may not be able to resend the requested data, ignores NAK - 'not supported' replies, keeps repeating the retransmit request and in consequence effectively breaks the connection as no subsequent data is accepted anymore. This seems to be violating the specs:
7.2.3
If a Device does not implement the Retransmit mechanism, it shall reply to the Retransmit Request Command
with a NAK Command with reason 0x01 (Command not supported). See Section 6.15. The remote Device should
not send Retransmit Request Commands after that.
I tried sending 'session reset' commands after the NAK reply, but those are ignored as well.
Expected behavior
I would expect the server to accept that some data unfortunately has been lost and just keep going.
Additional notes
MIDI Service installation is fully 'retail' as delivered and activated by Windows Update. No hotfixes have been installed manually.
Some more observations with the Network MIDI preview not directly related to the above (Some of these may just reflect the preview / alpha state):
On machines with multiple network interfaces multiple host sessions will be announced, but they are indistinguishable by their default names (all called 'Windows COMPUTERNAME'). Invitations on the WiFi interface are occassionally answered on ethernet and vice versa.
When inviting a remote session the server uses the client's endpoint name as its endpoint name. That makes sense from the server's point of view, but can be a bit confusing when dumping data on the client side or going through Wireshark captures. As with the hostnames above some prefix or marker would be welcome.
I don't think that letting the server pick a random port number for host sessions is a good idea. That will break all automatic setup and reconnect scenarios. The optional 'fixed' port number entry in the 'advanced' settings does not seem to work at the time being, but I would anyway suggest to make 'random port' the advanced option or drop it entirely.
Repeatedly connecting and disconnecting remote sessions may work fine, but often a 'Disconnect' does nothing (no BYE is sent) and usually the service crashes a couple of seconds later then.