- 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
With the exception of steam_api_common.h, which is mostly a stub,
these files are now identical with the Steamworks SDK.
Note that this also removes a check for STEAMNETWORKINGSOCKETS_OPENSOURCE
to try to set the structure packing consistently. However, due to an
order-of-include bug (see issue #176), this wasn't actually working anyway,
and probably isn't the best approach.
P4:6610285
Only x86_64, aarch64 and s390x are specified as 64-bit, but there are more 64-bit architectures, e.g.:
- mips64,
- powerpc64,
- powerpc64le,
- riscv64.
Those are not on the list. Of those, I checked that GameNetworkingSockets builds fine on powerpc64le with this change.
Signed-off-by: Fletcher Dunn <fletcherd@valvesoftware.com>
This won't work without Steam (STEAMNETWORKINGSOCKETS_ENABLE_FAKEIP
won't ever be defined here). But to make sure we can always share
the headers between this code and Steamworks SDK, the interface functions
will still exist.
P4:6571466,6571469
Separate "get info" and "iterate" tasks into two different functions.
Have the "get info" function just return the name, since that the most basic piece of info.
Delete the EnumerateDevVars config value. That's too subtle and a bad design
Just always pass that option into the enumeration function.
P4:6571450
In general we try to make sure a given header can be shared with the
Steamworks SDK. I've move this into a better place when we bump the
version number and release a matching SDK.
Now we store the userdata in a config value, so that it can be set
atomically when a connection is created, and also so that the default
value of -1 can be customized.
Also added some warnings about the dangers of using the userData
field in callback structs. I worry I've created a footgun here, and
would be tempted to remove the field entirely from
SteamNetConnectionStatusChangedCallback_t, but it is coming in
through a member struct SteamNetConnectionInfo_t, and it makes
sense there.
Addresses problems discussed in issue #162.
P4:6354936
steamnetworkingtypes.h:202:3: warning: anonymous types declared in an
anonymous union are an extension [-Wnested-anon-types]
Honestly surprised we haven't hit this before already. A partner
found the warning in the Steamworks SDK version.
Removed the word "custom" from the namesofinterfacesthatwerealreadyverylong.
Added k_ESteamNetworkingConfig_Callback_CreateConnectionSignaling, which is
a mechanism for connections that require signaling to be iniated locally.
This is used by ISteamnetwrokingSockets::ConnectP2P and connections created
using the ISteamNetworkingMessages interface....which has been added.
These changes address issue #137 and bring the opensource code more in
line with Steamworks version.
Delete the define STEAMNETWORKINGSOCKETS_HAS_DEFAULT_P2P_SIGNALING. "Default
signaling" is a thing that can exist on any platform, and can only be determined
at runtime. Most places that were using this actually should have been
checking STEAMNETWORKINGSOCKETS_ENABLE_STEAMNETWORKINGMESSAGES anyway, and
those two defines were equivalent in practice.
STEAMNETWORKINGSOCKETS_ENABLE_STEAMNETWORKINGMESSAGES will be defined by default.
I could add a mechanism to disable it if anybody is relaly concerned about
code size.
(Also started some refactoring of the P2P listen sockets, to merge them
with hosted dedicated server listen sockets. The goal is to enable a
way to connected to hosted dedicated servers without tickets. That is a work
in progress, and also not relevant to the opensource code.)
Thse headers are now *almost* identical to the one in the Steamworks SDK,
which makes it much easier for me (and possibly others) to switch between
a standalone lib and the Steamworks one, even at runtime.
Don't conditionally remove functions from the interface. This makes them
have different ABIs and the same code cannot be compiled to target either
one. Move STEAMNETWORKINGSOCKETS_ENABLE_SDR into a private header, and
provide stubs for all of the functions when it's not defined.
Global accessors that are defined to access code in the standalone lib
will have _Lib on the end, and the Steamworks ones will have SteamAPI().
And, if you are only compiling with one or the other (the common case),
then also declare the "undecorated accessor" to go to that one.
Added a steam_api_common.h stub which will define the very few things
that we need that are defined in that file in Steamworks.
There is one remaining cause of ABI differences, and that is structure
packing. The Steamworks code does really unfortunate things with
structure packing, which cannot be fixed now because of backwards
compatibility. That ship, unfortunately, has sailed. I made a different
decition with the opensource code, but if we do want compatibiilty with
the steamworks version, we will need to do the bad thing steamworks does.
This only affects certain platforms. I'll leave it alone for now,
but we might need to revisit it in the future. I think right now
the number of people who just want the opensource version to have the
same ABI regardless of platform (e.g. for C# wrappers) is more than the
number who might wany the ABI to be the same as Steamworks.
I closed issue #93, even though it was not fully resolved. This
change actually totally resolves it (with the exception of the
structure packing).