Yes, it probably should. In practice, if you have a connection that can even handle UDP then this initial UDP packet will almost always make it.
If you’ve created a network connection to a server that wants to send you UDP then it needs to have UDP setup in order to be “connected”. There isn’t a way around that. Should the client keep sending one every so often until connected? Maybe. How often? Is it longer than the user will wait and just try again anyway?
Anyway, this part is a little kludgy because it happens so rarely. The client should probably resent once every few seconds for X number of seconds before timing out. The code to do it just isn’t very pretty.
Makes sense. Thanks for the info.
So my latest wrinkle… Because of how steam p2p works if you connect to yourself then the p2p connections read and write from same source. So if you try to send a message from the client then then client commonly reads the message you just tried to send. This of course isn’t an issue for dedicated servers but it is for “lobby” games (IE games hosted from the client).
Didn’t even know it’s possible to connect to yourself with the p2p API. Interesting…
Well with the P2P api there really aren’t connections per say. It functions a little more like UDP. You can send whatever data you want to whomever you want as long as you have the SteamID to send to. This is especially annoying for disconnect conditions. I ended up having to add code to periodically check to see how long it’s been since we’ve received data over a connection as well as send a disconnect message from the client for normal disconnection.
Copying and building off the Spidermonkey default client and server turned out to be the way to go because of the oddness of working with steam p2p. I ended up needing to reserve the first 4 channels in order to deal with the self connection issue. I made the “Server” side read on channels 0 and 1 and send on 2 and 3. The client reads on 2 and 3 and sends on 0 and 1. It’s also allowed me to start with direct byte buffers instead of doing another copy inside the connection / endpoints.
At this point, I think the networking code is just about done. The hard part at this point is getting the SteamID to connect to in the first place. Dedicated servers are pretty easy to work with, but self hosting games require a lot of hoops to jump through. At least in Spoxel’s case it does. I had to write code to create a lobby, then once it’s been created register your steam ID as the game to start it but only once the server is running, then once the steam ID has been registered you can go into the game. In order to join you have to find the lobby ID → join the lobby → wait for the game to start or check if the game has already been started → grab the ID → connect. Spoxel has the extra wrinkle that I have to let users select a character before they connect so there are extra steps in there.
Looking forward to examining your code to see where I failed.
Hey guys, are there any news?
I haven’t had a chance to repackage the code in a separate lib yet. So far it has been at least somewhat battle tested by my beta testers and I haven’t run into any problems related to the framework I made. There are still a few areas I need to clean up. That being said… the networking all works, but you have to write a lot of boiler plate code to make it useful with steamworks4j. All the connections are based on SteamID’s.
Sounds good Is there source code or patch to see what you have implemented? This way, others may be able to give advice on how to make further improvements.
Edit: I bet pspeed our network lord has some nice ideas.
In this case they are completely separate classes but I just haven’t moved them into their own repo and added the proper headers. Right now I am just swamped with trying to release Spoxel this year. If I miss that deadline then I should have some time soon.
is there any progress on this? Did you have time to separate the classes? We are currently refactoring our network infrastructure and some help would be appreciated
I did, but I haven’t finished setting it up as a good add on lib yet. I know there is also a channel bug that I haven’t had a chance to fix yet. I don’t use channels for spoxel so it wasn’t an issue at the time. I’m still going back and forth about if I should add some sort of app state that handles basic steam usage as well. I’ve been taking a short break now that spoxel is out and i’m starting to pick up on other projects. This one is on my list to finish.
There are news about that. Steam released a new Sockets API. Maybe this is more usable than P2P connections with jme spidermonkey?
Steam’s latest networking lib release is yet another networking layer they’ve added. This is their 3rd now. I think this one is somewhat open source, but at the moment is still pretty tied to steam. I’ve looked into the steamworks version of it and there are a few nice features it adds. I’m waiting to see if steamworks4j implements the api at all before I look into it though.