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).
I let certain allocations go thorugh the CRT on purpose. Specifically,
allocations that happen at static init time must go through. Unfortunately,
MSVC's std::vector and std::map default constructors will allocate memory (!!!!)
with _ITERATOR_DEBUG_LEVEL > 0, so any such object at file scope will, for
now at least, not use the custom allocators.
Previously ISteamNetworkingSockets was plumbed through much more invasively.
But with the changes to callbacks, symmetric ocnnect mode, and P2P
connections automatically using internal loopback when sending to self,
now it is possible to implement ISteamNetworkingMessages much more as a
seperate layer on top.
ISteamnetworkingMessages is a P2P interface that is more like UDP. You don't
listen or connect, and you don't deal with connection handles. Instead, you
specify the remote address with each send call. The purpose of the API is to
make it easier to port UDP code to P2P. It's not currently part of the
opensource code, and has not yet been released in the Steamworks SDK. But I
probably will soon, once we have some good P2P example code. The previous
incarnations of the interface were kind of crap. I finally have something
worth releasing.
Now you can register standard function pointers, instead of deriving
from a special class. This means that Steam and the opensource code
can now work the same, so this fixed issue #124
This is a P2P feature for a common use case:
- The two peers are "equal" to each other. (Neither is clearly the "client"
or "server".)
- Either peer may initiate the connection, and indeed they may do this
at the same time
- The peers only desire a single connection to each other, and if both
peers initiate connections simultaneously, a protocol is needed for them
to resolve the conflict, so that we end up with a single connection.
Also added remote virtual port to ConnectP2PCustomSignaling
Also, copy over the declarations for functions that require SDR.
They are behind STEAMNETWORKINSOCKETS_ENABLE_SDR, so there is
no real reason to remove the code. It just creates merge conflicts.
On Steam these are only used internally, since we always have SDR
fallback. But without SDR fallback these will end up being the
mail failure code, if the connection fails.
This change includes many changes to improve P2P connections. I didn't
bother replaying them one at a time from perforce.
Changed the plumbing of how data packets are sent, using context structures
more. The main goal of these changes is to remove the assumption that data
packets are always sent/received on the currently selected transport. Also,
I removed two specialized end-to-end messages for ICE transport and SDR P2P
transport. Now all end-to-end packets are ordinary data packets (just without
any data). This is good because, for UDP, they are encrypted. (For SDR
connections we don't encrytpt them, because we want the relays to be able to
observe them and perhaps mutate them.) And is reduces the number of different
packet types and codepaths that need to be supported. This does have one
unfortunate downside: the receiver does not know which transport is used to
send dropped packets. So, any out-of-band checks on alternate transports,
which do not contain data, and are much more likely to drop (since the
transport is not selectged) will be observed as a gap in the end-to-end
sequence number. Oddly, the sender actually will have the more complete
picture (albeit after some delay), since he knows the outcome of every
single packet, and he knows what transport was used to send it.
Added a flag that can be used to indicate to the peer, "I am not using this
transport as my primary transport." My protocol does not have an explicit
nomination framework. Instead, any data packet that doesn't have this flag
is considered a nomination.
SNP now needs to remember what transport was used for each outgoing packet.
Added some plumbing so that I can collect data about how often ICE is
successful, how the routes compare to SDR, and if it fails, what progress
it made.
The ICE session interface offers more control over what kind of candidtes to
gather, and returns more detailed info about the candidates and route. The
goal here is to allow a semi-private mode. If you don't want to share your
public address with random Internet peers (to avoid getting DDoSed), but you
do want to get a LAN connection to any peers in your office / dorm (where LAN
broadcasts may not discover that you are on the same LAN), you can choose to
share only local addresses. This seems oddd to only share the "private"
address while keeping your "public" address a secret -- but in this case
the "private" address is actually more sensitive, and the public address is
the one that script kiddies would need to boot you. We are dealing with a
differet kind of thread here. The option to go totally private and disable
ICE completely, or only share relayed candidates, or only share public
addressses, are all still available, if the threat model is different.
When linking with Steam, these call ISteamNetworkingUtils functions, and
GCC complains if it hasn't seen that class. Even if you don't ever call
any of these functions, GCC doesn't like the fact it could not generate the
code if you were to do so. Not sure what the spec says, but it feels like
Visual Studio's approach makes more sense here.
These are really useful, and since everything inline, and calling functions
that we are already obligated to support, there is no extra maintenance
burden.
Derive TransportPopulateConnectionInfo on all the transports to
populate this field.
The ICE transport (the one we actually care about the most) is
unfortunately not fully plumbed up so that we know how we are relayed.
Will plumb that through soon.
The standalone library was defining some of the same symbols as the flat
interface in steam_api.dll, and this was leading to complications. Renamed
those functions, and they are not part of the "flat interface", they are just
global internal functions functions.
Added wrappers in the flat interface with the same name to pass thorugh. So
if the library is compiled with the flat interface (which we do in the
opensource version), no functions are removed and the flat interface stays the
same.
Steamworks SDK has found itself in a really bad place having to support ABIs
that differ on different platforms. That didn't matter in the days when
everybody compiled all of their binaries per platform, but it breaks the
"write once, run anywhere" ideal. We don't have to support old ABIs so let's
just pick a packing and use it everywhere. (But note that we do have stucts
with pointers in them, so our structs will vary between 32-bit and 64-bit.)
https://github.com/nxrighthere/ValveSockets-CSharp/issues/8
- Got WebRTC transport class started.
- Added steamwebrtc interface header. This is some work that SamL did for
Steamlink, to isolate all the webrtc build requirements from our code. I'm
not sure what the final version will look loike, but this is a good place to
start, since this library already exists and I can get a proof of concept
working. After we're working, I'll probably peel back the layers a bit and
refactor this, and then eventually figure out how to opensource that work.
- Added config values to set the STUN server list
- Bring in interfaces for custom signaling from Steamworks SDK.
- Promote some stuff related to ISteamNetworkingMessages to base class.
It is hidden behind STEAMNETWORKINGSOCKETS_HAS_DEFAULT_P2P_SIGNALING.
- Add STEAMNETWORKINGSOCKETS_ENABLE_SDR in a bunch of places.
- Add CSteamNetworkConnectionBase::AsSteamNetworkConnectionP2P so we
can compile without RTTI.
Fletcher Dunn
Steven Noonan