感谢 @aerodomigue 的稳定性修复建议

[yunsmall]

感谢 @aerodomigue 在 fork aerodomigue/usbipdcpp 中做的稳定性修复工作。以下修复已合并到 upstream develop 分支：

竞态条件 & 稳定性：

• handle_unlink_seqnum 共享锁提前释放导致 use-after-free
• transfer_callback 中 LIBUSB_TRANSFER_ERROR 处理逻辑反转（SHORT_NOT_OK 判断反了）
• pending_count_ 递减过早，与 on_disconnection 存在竞态
• receiver 线程绕过 sender 队列直接写 socket 导致并发写入
• sender TCP 写失败后仅 break 退出，session 未及时清理
• immediately_stop 未唤醒 sender 线程

设备管理：

• release_and_close_device 设备拔出后反查接口数量失败导致释放循环被跳过

新功能（参考 fork 设计）：

• LibusbServerConfig 配置结构体（skip_hub, auto_bind_hotplug）
• bind_existing_devices() 启动时自动绑定所有设备
• daemon 模式（POSIX sigwait）
• Windows Service 示例

@aerodomigue 是否有兴趣向 upstream 提 PR？非常欢迎！

[aerodomigue]

Hi @yunsmall,

Thanks for the kind words and for merging the fixes — glad they were useful!

Additional fixes in my fork not yet upstream:

• libusb_clear_halt() returning LIBUSB_ERROR_OTHER caused an endless Windows retry storm (~75 req/s) — some devices respond unexpectedly to CLEAR_FEATURE(ENDPOINT_HALT)
  when the endpoint is not actually halted; treating it as success per USB spec §9.4.5 stops the loop
• TCP keepalive on sessions to detect dead clients (e.g. Windows reboot without clean disconnect)
• Anti-spam guard in bind_existing_devices() to avoid log noise on every session poll

Features I'd be happy to contribute upstream (opt-in via config flags):

• UDP broadcast on device bind — toggleable via LibusbServerConfig.udp_broadcast_port (0 = disabled)
• Hub filtering and specific device exclusion — already partially in your LibusbServerConfig, could be extended with an exclusion list
• Windows auto-attach service (tools/windows/UsbIpAutoService.cs): a .NET Windows service that auto-attaches all USB/IP devices on startup, listens for UDP hotplug
  notifications, and detaches cleanly on shutdown

I can open a PR with the generic fixes + opt-in features, keeping my deployment-specific logic in my fork. I've also translated all Chinese comments and strings to English,
which could help international contributors.

One request: would it be possible to use English as the primary language for issues and PRs? Chinese isn't my native language (French is), and English makes it easier
for future contributors from any background to participate.

Context — why I need UDP broadcast:
My setup is a Raspberry Pi behind a KVM switch shared between a Mac (local) and a Windows PC (remote via USB/IP). When the KVM switches to the Pi side, devices hotplug in and
the Windows client needs to auto-attach them instantly — polling would add noticeable latency on every switch.

Keyboard / mouse / mic / PS5 controller
               │
          KVM switch
          ┌────┴────┐
       Mac Mini   Raspberry Pi 4 (usbipdcpp)
                       │  [network]
                  Windows 11 PC (USB/IP client)

Happy to contribute!

[yunsmall]

Hi @aerodomigue,

Thanks for the detailed explanation of your setup and the fixes/features you'd like to contribute.

Here's my take on each item:

Fixes — welcome as PRs

• libusb_clear_halt() retry storm — makes sense, treating LIBUSB_ERROR_OTHER as success per USB spec §9.4.5 is reasonable. Please open a PR.
• TCP keepalive — useful for detecting dead clients. It's a TCP-layer safety net, not related to the usbip protocol itself. Happy to take it.
• Anti-spam guard in bind_existing_devices() — sure.

Features — callback-based approach

Instead of hard-coding UDP broadcast or device exclusion lists, I'd prefer callback-based hooks in LibusbServerConfig. Users can register callbacks for filtering and event notification — the library doesn't care what protocol or logic you use on top.

Interface design:

// Callback to decide whether a USB device should be listed for USB/IP export.
// Return true to skip the device (it won't be available to clients).
// Called in bind_host_device() and bind_existing_devices().
using DeviceBindFilterCallback = std::function<bool(libusb_device *dev, const libusb_device_descriptor &desc)>;

// Device event type
enum class DeviceEvent { Bound, Unbound, Removed };

// Device event callback: called when a device is bound / unbound / removed.
using DeviceEventCallback = std::function<void(LibusbServer &server, DeviceEvent event, const std::string &busid)>;

Changes to LibusbServerConfig:

struct LibusbServerConfig {
    bool auto_bind_hotplug = false;
    // Filter callback: decide which devices are visible for USB/IP export
    DeviceBindFilterCallback device_bind_filter;
    // Multiple event callbacks, iterated on invocation
    std::vector<DeviceEventCallback> event_callbacks;
};

Call sites:

• DeviceBindFilterCallback — called in bind_host_device() after fetching the descriptor. If set and returns true, the device is skipped (not listed for export). Users compose their own logic (by class, VID/PID, whatever) in a single callback. The existing skip_hub option can be deprecated in favor of this.
• DeviceEventCallback — called with Bound after bind_host_device() succeeds, Unbound after unbind_host_device() succeeds, and Removed inside handle_device_left(). All three pass *this, the event type, and the busid.

Usage example:

LibusbServerConfig config;
// Skip hub devices (not useful for USB/IP export)
config.device_bind_filter = [](libusb_device *dev, const libusb_device_descriptor &desc) {
    return desc.bDeviceClass == LIBUSB_CLASS_HUB;
};
// UDP broadcast on device events
config.event_callbacks.push_back([](LibusbServer &server, DeviceEvent event, const std::string &busid) {
    udp_broadcast(event, busid);  // user's own implementation
});

LibusbServer server(config);

This keeps the library protocol-agnostic while giving you the UDP discovery you need. You just register a callback that sends the broadcast — the library handles the rest.

Windows auto-attach service

This is a client-side tool (it calls usbip attach), not a server feature. usbipdcpp is a server library, so it doesn't quite fit here. It would make more sense as a standalone project.

Language policy

• Public API documentation (doxygen comments on classes, functions) will be in English.
• Internal implementation comments can be in Chinese or English. Let's keep it to these two languages upstream — other translations (like the French in your fork) are best kept there.

Feel free to open PRs for the fixes above and the callback system — the approach outlined above is the general direction, but the implementation details are yours to decide. Looking forward to your contributions!

One note: the fixes mentioned in the issue body (race conditions, release_and_close_device, daemon mode, etc.) were implemented independently on this side rather than taken from your fork. So your fork may need a rebase onto upstream first — some of the existing commits there are likely redundant now.

[yunsmall]

Just to add — the code snippets above are only meant to sketch the general idea, please feel free to shape the actual implementation however you think is best.

Also, I wanted to clarify the language policy a bit: runtime messages (log output, error messages, etc.) can be in English too — same as doxygen comments. Whatever makes things clearest for users.