NET: Add SO_RCVBUF / SO_SNDBUF defaults to .._bnet_socket #9127
Conversation
rpcs3/Emu/Cell/lv2/sys_net.cpp
Outdated
| if ((native_flags & MSG_PEEK) && get_native_error() == WSAEMSGSIZE) | ||
| { | ||
| native_result = len; | ||
| WSASetLastError(0); |
There was a problem hiding this comment.
Those 2 WSASetLastError(0); are not needed, we only check error on api call failure and by then the error would have been set to the new one.
Apart from that I'm fine with this PR.
There was a problem hiding this comment.
Will we hold a separate per-thread error value that we explicitly update in each net function to allow us to handle the _sys_net_errno_loc() call eventually?
The WSASetLastError(0) was just 'stolen' from cygwin, I figured we'd be implementing pretty much the same kind of thing as they have (translation from posix <-> native Win32), but that was on the assumption there would be a PS3 get_errno type of function call (rather than a function to return a pointer to the errno value)
There was a problem hiding this comment.
I've not delved too deep into this but sys_net_errno is not a syscall, it's part of a firmware library. It's probably updated depending on return values from the syscalls and handled by the library.
There was a problem hiding this comment.
Ok, I've dropped them out for now then.
Do we have any standard way of tracking the address offsets into TLS?
I see that for the _sys_net_errno we have "ppu.gpr[13] - 0x7030 + 0x2c", and I've seen similar around.
My perhaps naïve thought was that an enum or similar for the TLS storage variables (offset) would have allowed better traceability, or is it really not (supposed to be) known at compile time? [i.e. our current use of constant is a workaround]
There was a problem hiding this comment.
_sys_net_errno is part of libnet which is lled, which is why most functions are unimplemented, like I said previously it doesn't matter.
The OS defaults for SO_RCVBUF / SO_SNDBUF may not match what the defaults for the PS3 are. And the code may be happy with the PS3 defaults, so may not set this explicitly. So we'll do it when we establish the socket. It also looks like the Windows recv behaviour is different for the MSG_PEEK option (and possibly in all situations where a smaller buffer is provided). I believe other platforms will return the size of the data received into the socket buffer, even if the supplied user buffer is smaller. Windows returns WSAEMSGSIZE instead. For the length of '1' MSG_PEEK request that is currently seen, we just mask this and return the full size of the buffer. This might need to be the case in all situations, I assume there will be applications that will supply an artificially small buffer and resize it as necessary based on the size of the received packet. Add some additional translations from native->PS3 error codes Rewrote handling of MSG_PEEK to just be a copy of what GalCiv suggested Added WSAESHUTDOWN, and WSASetLastError as done by Cygwin
The OS defaults for SO_RCVBUF / SO_SNDBUF may not match what the defaults for the PS3 are.
And the code may be happy with the PS3 defaults, so may not set this explicitly.
So we'll do it when we establish the socket.
It also looks like the Windows recv behaviour is different for the MSG_PEEK option (and possibly in all situations where a smaller buffer is provided). I believe other platforms will return the size of the data received into the socket buffer, even if the supplied user buffer is smaller. Windows returns WSAEMSGSIZE instead. For the length of '1' MSG_PEEK request that is currently seen, we just mask this and return the full size of the buffer. This might need to be the case in all situations, I assume there will be applications that will supply an artificially small buffer and resize it as necessary based on the size of the received packet.
Add some additional translations from native->PS3 error codes
Rewrote handling of MSG_PEEK to just be a copy of what GalCiv suggested
Added WSAESHUTDOWN, and WSASetLastError as done by Cygwin