Added bDeleteFailedMessages. By setting this to false, the caller has
the opportunity to retry failed messages, which is an especially
reasonably thing to do in the case of the send buffer being full.
Also clarified expected (and enforced) expected behaviour on
how subsequent messages on a connection are handled after a failed
message send. Previously, there was a fairly significant bug, which is
that we would coutinue to try to send messages, which is bad because
it can break fundamental guarantees about message delivery order. Now,
we will always stop at the first failure.
This fixes issue #317
They are swapped for historical reasons. (It's too dangerous/
difficult to change the API to the more intuitive order.)
So, I just added comments to clarify exactly what the behaviour
is, and renamed a bunch of variables to hopefully make the code
more clear, too.
This addresses #404
C-style cast from `uint8*` to `uint64*` is unsafe and can blow up
in cases when the source pointer is not aligned to `uint64` type
requirements.
Signed-off-by: Pavel Solodovnikov <pavel.al.solodovnikov@gmail.com>
(cherry picked from commit 5a7c2dd482)
Now, -1 means "auto" and 0 means "don't set anything".
Add g_nSendECNAuto
Add ResolveECNSendGlobal
P4:9166210,9168032
(cherry picked from commit fcc19e1368)
This is disabled by default.
Added k_ESteamNetworkingConfig_SendTimeSincePreviousPacket to enable it.
NOTE: In order to enable a sender to know whether the receiver will be able
to decode the value, we need to bump k_nCurrentProtocolVersion.
P4:9135136
(cherry picked from commit 14956c67f5)
The documentation was, uh, aspirational. Eventually I'd like to have it work
that way, but until we have bandwidth estimation the current behaviour was
really pretty busted.
This fixes#270
RecvMaxSegmentsPerPacket
This is exceedingly useful for games that only use SteamNetworkingSockets
for "datagram transport" over SDR, and do not want to use the reliability
layer or message fragmentation, reassembly, packing. In this case,
1 message = 1 UDP packet, and allowing more messages per packet is really
just an opportunity for an attacker to amplify their attack. Relays
provide packet rate limiting, but since they do not terminate the
encryption, they cannot look inside the end-to-end payload and thus cannot
help enforce message rate limits.
But even for games that are using our framing layer, if you knowyour
traffic pattern and know you never send 500 tiny messages at once, you
can lower this limit and gain a little bit of protection.
We probably are going to need to add a token bucket message rate limiter
at some point.
P4:7421833
- minbase_identify will now check for _GAMING_XBOX_XBOXONE and
_GAMING_XBOX_SCARLETT. (And also _GAMING_XBOX)
- Added IsXboxScarlett() and IsXbox()
- A few places in the low level code need to be tweaked based on IsXbox()
instead of _XBOX_ONE
- Added IsIOS() and IsTVOS()
Deleted some code that was disabling warnings, I don't think it's needed
anymore.
Tweak defines in CSteamNetworkingUtils::GetPlatformString
PS4/PS5 need Microsoft-style __declspec(dllexport)
P4:7324318
Replace a bunch of non-standard defines with standard ones
Don't #define POSIX in public header or test for it. Fixes#228.
(We shoulkd probably also make this change to Steamworks headers.)
Use IsLinux(), IsPosix(), etc instead of #ifdef LINUX or #ifdef POSIX
Moved some platform socket stuff out of steamnetworkingsockets_platform.h
and into platform_sockets.h. (none of this is actually particular to
steamnetworkingsockets.)
Some platforms don't have IPv6 support.
Visible changes:
- Uncomment ConfigureConnectionLanes
- Rename GetQuickConnectionStatus to GetConnectionRealTimeStatus, and change
the prototype to return information about multiple lanes.
- Adding a test case to send data on more than one lane and make sure we get
the priorities we expect.
- Also refactored the test-connection so that you specify what test(s) to
run on the command line, instead of using the LIGHT_TESTS compile-time
option.
- Bump interface version numbers.
Internal changes/bugfixes:
- Fix bug with my implementation of fair queuing. I was always calculating
the finish time for a lane based on the current virtual time. But really
it must be calculated from the time when the previous message in the same
lane finishes. Otherwise you don't share the bandwidth properly when it
alternates lanes. To keep the implementation simple, I just tag each
message with the virual finish time. I believe that this can actually
cause the virtual time to go in reverse if you queue a message on an idle
lane and we swap the active lane while sending is in progress. But I
think it's OK right now, and we will actually do the right thing and get
back on track after a message or two. To make room for this variable,
I shuffled around how we had shoved in reliable bookkeeping in
CSteamNetworkingMessage.
- Fix bug selecting the next message to send. We were ignoring the priority
classes and just using virtual time!
- Fix some bad hex math encoding and decoding the lane select frame.
- Fix some bugs that were confused about which set of links were used to
track the list of messages in a particular lane
- Fix bug when serializing segments from multiple lanes, only one of the
lanes will get to take advantage of the special segment encoding where
the segment length is implied by the packet size.
- Reorder the fields in SSNPSenderState::Lane to pack them a bit better
Fixes issue #95.
P4:6865294
- Added VirtualPortRender, which can be used to show symbolic names to the
"messages" vport and the fake UDP port vports.
- Replace "vport %d" with VirtualPortRender calls in several debug output
call sites.
- Improve and refactor CSteamNetworkConnectionP2P::GetConnectionTypeDescription
to handle fake IP and vports smarter.
p4:6865178
Implement packet decode for the lane select frame. I have not executed all
this one single time! (But I have been making sure I haven't broken the
single-lane case.) If I have not written any bugs, the the feature almost
done!
Remaining work:
- Write test harness, make sure it does actually work...
- Bump versions, deal with old peers who don't understand lanes, etc.
Also, add STEAMNETWORKINGSOCKETS_MAX_LANES.
- Add some optimizations if STEAMNETWORKINGSOCKETS_MAX_LANES is small.
In particular, STEAMNETWORKINGSOCKETS_MAX_LANES=1 disables support,
and all the code is compiled out.
- Also this can be used to limit the amount of work a malicious sender
can make a receiver do.
P4:6819330,6819343
- Updated wire protocol document
- Implement encoding for multiple lanes.
- Added function declaration to ISteamNetworkingSockets with rather copious
documentation. (But left it commented out for now, until it all works).
Remaining work:
- Implement decoding
- Bump versions, deal with old peers who don't understand lanes.
- Add tests
P4:6819091,6819098
- Added a system for strict priority classes, in addition to the "weight"
system. The combination of these two makes for a very flexible system,
while also hopefully being easy to understand.
- Each lane has its own message number sequence. This has several
advantages:
- It makes it clear that the order of messages between lanes is
not guaranteed
- It greatly simplifies packet encoding/decoding. (Going to make some
more progress on that next.)
(Based on discussions with jeffreyh@valvesoftware.com. Thanks!)
P4:6818689,6818692
Lanes are different messages queues with different priority levels.
Work in progress. This change just adds some data structures, but
the actual wire encoding/decoding not yet implemented.
See also:
- Issue #95
- https://twitter.com/Mokosha/status/1444009029987041281
P4:6806862
Fletcher Dunn
Brad Smith
copyrat90
Pavel Solodovnikov
Hussein Ait-Lahcen
Jeff Hill