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
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
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
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
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
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).
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.
- 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.
This is used to poll many connections in a single function call. Previously,
this was only possible if all of the connections were those accepted on the
same listen socket. (ReceiveMessagesOnListenSocket). But this left out at
least two important use cases with known users:
- If you create more than one listen socket (because there is more way to
contact your service, e.g. once for P2P and another for direct IP, and
another for relayed connections), then you could not poll all of the
connections efficiently.
- In P2P use cases, we may initiate many connections to peers, and we want
to poll all of them at once.
This change is relevant to: Issue #49, Issue #50, and issue #52. (But I don't
this it really "fixes" any of them.)
The connection will be responsible for end to end stuff including encryption,
message fragmentation and reliability, etc. Transports deliver datagrams. A
transport is always associated with a single connection, but a connection may
have more than one transport, and may switch between transports over the course
of the connection lifetime.
The goal here is to have conenction types that can switch transport.
Specifically, we need to support a connection that can detect when peers
are on the same LAN and use ordinary UDP in that case, attempt NAT piercing
using STUN, and if that fails, then relay (either using TURN or SDR).
There is more work to be done here. For example, each transport almost
certainly has its own ping time and quality characeristics, so we probably ought
to track some stats there. (But our stats situation is already getting pretty
crazy, so maybe just track ping seperately).
This change also includes some changes relevant for Steam Remote Play
streaming, which is going to use this protocol for relayed connections.
(And eventualy, hopefully, for all connections.) For example, steam remote
play needs really high bandwidth and packet rate, and the tolerance for
sending the timing data for jitter tracking was too tight. I also need to
pass a "certificate" to a subprocess in a single blob, which actually includes
the private key.
Also:
- STEAMNETWORKINGSOCKETS_STEAM now mens "running on steam", not "running using
the steam client". STEAMNETWORKINGSOCKETS_STEAMCLIENT is for that.
- Refactored stats stuff, moved it into the namespace. At one point I thought
I might expose some stuff in a public interface. For now, keeping it internal.
- Removed concept of Steam "universe" from this branch of the code.
- Don't use OVERRIDE, override works.
Added documentation about SteamNetConnectionStatusChangedCallback_t. This is an
important callback, so it's been pretty bad that it was essentially undocumented
until now.
Also use ESteamNetworkingConnectionState instead of int. (I have taken steps
to make sure that the enum is the right size.)
The notes about ISteamNetworkingUtils::InitializeRelayNetworkAccess are not
relevant in the opensource context.
Moved them to ISteamNetworkingUtils, which is now actually shared Steam (mostly) with a real accessor and and interface, and not a dummy interface object with all static methods.
Connection settings have a system of inheritance, so they can be set globally, per SteamNetworkingSockets interface, per listen socket, or per connection.
Deleted the config variable to simulate fake *message* loss. That is not useful.
Introduced STEAMNETWORKINGSOCKETS_ENABLE_SDR define, to make it more clear why code is being #ifdef'ed out. (E.g. if we open-sourced that code, we would want that included.)
Replaced ESteamNetworkingSendType with a basic flags bitmask.
Cleaned up a bunch of comments.
Changed SteamNetworkingMessage_t release mechanism. Now the callback is only to free the buffer, and it's assumed that this API will manage the actual objects. (This is important because the actual type is a derived type and has extra stuff on the end.) Also laid some groundwork for user management of message objects. (Relevant for issue #51.)
Also moved a bunch of Steam-specific stuff to other files, which are not included in this repository.
Moved high level init/kill to a seperate file, so that isteamnworkigsockets.h won't be cluttered with
a bunch of #ifdefs.
Added IClient interface layer, which is useless in this context, butneeded in Steam, since we
provide backwards compatibility for all old ISteamXxx interfaces.
Fletcher Dunn