[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Qemu-discuss] Qemu redirection option behave differently on Linux and W

From: Taimoor Mirza
Subject: [Qemu-discuss] Qemu redirection option behave differently on Linux and Windows
Date: Mon, 15 Apr 2013 22:00:38 +0500

Hi Everyone,

I am trying to use QEMU's port forwarding option with my application and have observed following difference in behaviour on Windows and Linux:

* If I relaunch QEMU with same host and guest port redirection values on Linux, it throws following error:
qemu-system-arm: could not set up host forwarding rule 'tcp:8080::8080'
qemu-system-arm: Device 'user' could not be initialized

This makes sense as first launch of QEMU creates a socket and binds it to host port 8080 and starts listening for connection. So any subsequent request to bind to same port fails that results in host forwarding rule error.

* But If I relaunch QEMU with same host and guest port redirection values on Windows, it does not throw any error and second launch also gets successful. But connection requests are only received by first launch's socket and second launch does not get any connection requests.

I looked at QEMU source code and found out that it sets SO_REUSEADDR socket option before binding to host port. It looks to me that behavior of SO_REUSEADDR option is different on Windows and Linux. 

On Windows, As per MSDN, "The SO_REUSEADDR socket option allows a socket to forcibly bind to a port in use by another socket. The second socket calls setsockopt with the optname parameter set to SO_REUSEADDR and the optval parameter set to a boolean value of TRUE before calling bind on the same port as the original socket. Once the second socket has successfully bound, the behavior for all sockets bound to that port is indeterminate. For example, if all of the sockets on the same port provide TCP service, any incoming TCP connection requests over the port cannot be guaranteed to be handled by the correct socket — the behavior is non-deterministic. “

Whereas on Linux, "SO_REUSEADDR socket option, which explicitly allows a process to bind to a port which remains in TIME_WAIT (it still only allows a single process to be bound to that port). The bind function fails to operate properly when the server terminates and we try to restart it immediately. Normally, the implementation of TCP will prevent us from binding the same address until a timeout expires, which is usually on the order of several minutes. Luckily, the SO_REUSEADDR socket option allows us to bypass this."

Is it expected behaviour?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]