Fix mDNS INBOUND_BUFFER_SIZE. Fixes Windows misbehaving. #515
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Currently, the
INBOUND_BUFFER_SIZE
is 512 bytes, which means that the data gets truncated in therecv_from
call instart
when the incoming payload is larger (happens a lot in our office network, for example).The problem is that this happens silently on Unix systems and everything works OK (well, the messages are truncated, but still). Unfortunately on Windows
socket.recv_from
actually returns an error in this case -WSAEMSGSIZE (10040)
and mDNS starts logging errors and doesn't behave the same.This is currently blocking us using using WebRTC via this crate on Windows.
For more info, see:
![image](https://private-user-images.githubusercontent.com/8321194/284634260-2d84781b-859e-468b-9ff8-7e99a09e57b9.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3MzkyNjE1NDEsIm5iZiI6MTczOTI2MTI0MSwicGF0aCI6Ii84MzIxMTk0LzI4NDYzNDI2MC0yZDg0NzgxYi04NTllLTQ2OGItOWZmOC03ZTk5YTA5ZTU3YjkucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDIxMSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTAyMTFUMDgwNzIxWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9MzRkY2Q1NDhmODJmNDM5ZGQ2MWZhMDg4ZmFlNjQ1NzI1MmM5MzE1Y2YzOWY2NzQ2OWU5NDFhOWVkMjY1ZDZmMiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.jX7fb0nkOUFY0fsHgzIHzI180C359s5twcAtCOch5PI)
https://docs.rs/mio/latest/mio/net/struct.UdpSocket.html#method.recv_from as excerpted here:
The UDP buffer can be up to 64k so this PR bumps it to the maximum size to avoid this difference in behavoir. Realistically, it'll almost never be above 1500 unless using jumbo frames or some other exotic network setup, but better safe than sorry.
The alternative would be to check the error message for
WSAEMSGSIZE
and treat it as success to behave like Unix, but unfortunately once an Error is returned fromsocket.recv_from
we can't get the length and address thatOk
contains.