[PATCH] ws2_32: Implement automatic broadcast for UDP sockets on sendto() (try 2)

[Bruno Jesus]

On Mon, Dec 5, 2016 at 12:09 PM, Hans Leidekker <hans at codeweavers.com> wrote:
> On Mon, 2016-12-05 at 11:28 -0200, Bruno Jesus wrote:
>> > You are trading correctness for performance, and even with this filter
>> > the getsockopt calls are probably too expensive. I guess this
>> > information should somehow be cached.
>>
>> I agree with you, it is a tradeoff. The filter is fast because the
>> patch reduces the scope of the test to only a few handful of packets
>> that are probably broadcast addresses, only then it will check the
>> broadcast flag and in the kernel this is very fast because judging by
>> the kernel source code. Only if previous conditions are met it will
>> check if it really was a broadcast address.
>
> It's still a context switch. Couldn't there be more than a handful of
> broadcast packets?
>
>> A different approach would be to let it hit EACCES when sending and
>> check for the error and only then do all tests, that would still work
>> and still be only a handful of packets but then we could check for the
>> broadcast address everytime without suffering from performance and
>> getting perfect correctness. What do you think?
>
> That would get rid of some the performance cost (more importantly it
> would no longer hurt the general case), but it would still require
> get/setsockopt calls for every broadcast packet.

Just as background: Old games used broadcast to help auto finding
other players in the same network, I have seen a handful of network
messaging programs that also did that to simplify file transfer by
finding if the user is in the same network avoiding a server relay.
Some games that use broadcast are Command & Conquer, Age of Empires
and Worms 2. This is not something you do 100 times per second, eg C&C
used a 3 second interval.

But none of these games are not affected by this bug. This bug is
about a very particular case in the broadcast implementation of
Windows that allows a broadcast without explicit SO_BROADCAST.

We have 2 case scenarios by using the EACCES approach:

1 - The socket is SOCK_RAW and that is why it was not allowed;
2 - The socket is UDP and SO_BROADCAST was not enabled.

The first is discarded as soon as we check the socket type, which uses
SO_TYPE. Then we will check if the SO_BROADCAST was disabled and only
then check the broadcast address. In other words, for every packet
that hits EACCES (overly extremely rare) we will call SO_TYPE and then
check the UDP stuff is required and if yes try resending the packet.

There won't be any performance hit in the standard socket usage (data
sending using tcp/udp), only when EACCES happens that we will need to
do something.