Sorry your browser is not supported!

You are using an outdated browser that does not support modern web technologies, in order to use this site please update to a new browser.

Browsers supported include Chrome, FireFox, Safari, Opera, Internet Explorer 10+ or Microsoft Edge.

Program Announcements / Multisync v1.0 - Multiplayer plugin

Author
Message
Agent
20
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 1st Jan 2012 07:03
Hmm. Two programs running cooperatively on the master server machine. Interesting! The "Ping Server" could connect to each Game Server one at a time, to see if they accept the connection. It could immediately drop, once successful, and move on to the next one. Any time a connection fails, it could insert a connection to the Master Server to tell it the last ping failed, then disconnect and move on to the next item in the list.

Hmm, complication. Both programs need to be running from the same list, and that list will need to be kept in precise sync. It's far better to use a single program. Files don't work - only one program can access the file at a time. Unless we use a direct location in memory we can't have a perfectly sync'd list.

Dr Tank
15
Years of Service
User Offline
Joined: 1st Apr 2009
Location: Southampton, UK
Posted: 1st Jan 2012 21:29
If you can't use a file, just have the "ping server" get the list from the "Master Server", the same way a user would.

I don't see any problems with syncing - the "ping server" gets a fresh list by periodically connecting to the "master server". This list won't always be totally up to date but it doesn't really matter.

The "master server" only recieves notification of failed pings from the "ping server", and takes those ips off its list, if they are present. (they may have already been removed due to a user host quitting gracefully).
Agent
20
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 2nd Jan 2012 06:14
Hmm. I'm not sure why I originally thought it was essential that the Master and Ping are running from the same list. When I think about it fresh today it doesn't seem like that's necessary at all - they just need to be close to sync.

Ping can do a run through every server in its serverlist and create a "deadlist" of servers that fail a ping response. When the whole serverlist has been checked, it can connect to Master and send the deadlist. Master receives the deadlist and removes those servers from its serverlist, transmitting the new serverlist to Ping, who disconnects and starts running through the serverlist again.

Noley
13
Years of Service
User Offline
Joined: 13th Dec 2010
Location:
Posted: 13th Jan 2012 00:16
Agent, your last post sounds like a really good idea.

You could try connecting "Ping" and sending a byte flag to the master server that identifies it as ping and holds connection until master server wants to do a refresh. Every X minutes/seconds/etc master server can send the server list to "Ping" and send it a byte flagging that "Ping" should do a run-through of live servers. "Ping" could respond with a byte telling master that it's disconnecting to do the run-through, then begins connecting to each server to check availability, when "Ping" encounters an unavailable server it could store that server's id in a variable and disconnect, re-connect to master server and send a byte flagging that the server with the id X is unavailable, then Master could remove the unavailable server from its list and send a byte to "Ping" informing it of the removal and then send ping a refreshed server list and packet directing it to check for availability as per the Master's timer.

Something along those lines, let me know what you think

Hopefully the thought helps

Sorry it's kind of a massive chunk lol
Agent
20
Years of Service
User Offline
Joined: 7th Sep 2004
Location: Sydney, Australia
Posted: 13th Jan 2012 07:21
Yeah. It's basically the same idea, but I wanted to have Ping only connect to Master a single time for each runthrough of the serverlist. Ping connects to Master, receives the current serverlist, disconnects, connects to each server, adding dead ones to the deadlist, finishes the list, reconnects to Master, sends the deadlist, waits for Master to send a new updated serverlist taking the deadlist into account, then disconnects and starts another runthrough.

Having Ping connect to Master each time it finds a dead server would be cycle consuming for Master, and Master would be pretty busy, since every time any client in the entire universe wants to connect to any server, anywhere, Master has to field a connection from him. So we want Master to be as stress-free as possible, so Ping will only bother him once per lap.

The downside of the slightly delayed deadlist update means that one or more of the servers a client receives from Master might be dead, since Ping hasn't updated Master just yet. But that's not uncommon in games that use a Master to keep track of Servers, so I don't think that's a real big deal.

And since the game I'm designing this system for is kind of a niche game (it's a 2D MMORPG in the oldschool style of Final Fantasy II etc) I'm not anticipating a high number of Gameservers, which means Ping won't require a lot of time to do a runthrough and Master will be updated frequently.

On the other hand, if the game becomes popular (who knows?) and hundreds of Gameservers pop up, this system might become sluggish. Time and testing will tell!

XFS Illusion
18
Years of Service
User Offline
Joined: 20th Apr 2006
Location:
Posted: 4th Feb 2012 12:12 Edited at: 4th Feb 2012 12:21
I've used tempest in the past, along with previous versions of Multisync. I've been on a .NET kick for a couple years now, but now that DBP seems to have a bunch of bugs fixed i'm thinking of switching back. There is no doubt that is is actually faster than .net in my opinion. Last week I wrote a plugin for DBP networking, but I think i'm going to give this a shot before I go much further with it.

One thing that does concern me. In the plugin I wrote, I was using TCP to manage connections, but going to use UDP for relaying player positions, etc. My reasoning is that when it comes to positions, what is current is more important than having the data verified in some cases. So i'm afraid using TCP in this engine may not produce enough speed compared to UDP, though it is more reliable. Of course I won't knock it until I try it. I figure even if it turns out I need UDP for some things, I see no reason why I can't use this MSync plugin to manage my connections and necessary data, and still use a separate UDP class on a different port for handling less important but time restrictive data transfers.

What I would recommend for future releases, is to have the option of using both TCP and UDP, assuming it doesn't have UDP now which I don't believe it does, but again, I haven't tried it out yet. I would be very interested in seeing the source code, but I understand if that cannot be made available. I noticed in the help file where it mentioned darkGDK, so i'm assuming it can be used with it...nice touch, even if it cannot be used with the .NET version(Doesn't seem to be too popular anyway, and i've had my share of problems with the .NET version of the GDK). .NET just seems to have too much overhead, I was mainly attracted to it for the system.socket libraries...but I'm starting to think that it isn't worth the headache. As for the DarkGDK, I messed with it too, its biggest attraction seems to be the C++ portion of it...but since it still can't be used as a cross platform tool with the GDK (as far as I know), seems we are stuck with Windows for the moment. If this wasn't the case then i'd love to write a game for linux. Anyway, this is just my two cents, seems i'm babbling now.

In either case, thanks for the plugin Ben...I was very pleased to see a more recent version of this plugin released. I cannot wait to give it a go. Also look forward to any future releases that may become available

This just leaves me with one question. Any idea how many players this plugin can handle in DBP? Just curious. Also curious what others on this board may think when it comes to a comparison of TCP vs UDP. I'll try to post my thoughts after I get this thing up and running in the meantime.
Juggalo Memnoch
16
Years of Service
User Offline
Joined: 22nd Apr 2008
Location:
Posted: 6th Mar 2012 06:19
Alright so I've been struggling with Multisync with DarkGDK for a while now and I just can't seem to get it working... I have no issues with making the connection through either LAN or the internet BUT I'm having a big issue with transferring data back and forth(Kind of important).. The server can receive the new players name but I'm having issues with more than one client, Any additional clients start overwriting the previous clients data. I don't know if it's just me being dumb, puttin things in the wrong place or what.. I hope someone can help me.

Server.h


Server.cpp


Client.cpp


This code is everything to do with the Networking but I've also included the Project folder as well..

Attachments

Login to view attachments
DeadTomGC
14
Years of Service
User Offline
Joined: 11th Aug 2010
Location: LU
Posted: 1st Jun 2012 05:00
I want to send a message to another client as a client while knowing that there is only one other client but not (currently) knowing the client's number.

How could this be done?


GreenDixy
16
Years of Service
User Offline
Joined: 24th Jul 2008
Location: Toronto
Posted: 29th Jun 2012 09:47
I had a question about ports for when a client connects. In any examples i have seen, There is no port setup in them. What is the default port number?

======================================
My software never has bugs. It just develops random features.
tokyomage
14
Years of Service
User Offline
Joined: 26th Sep 2010
Location: on your roof
Posted: 1st Jul 2012 01:28
Useful indeed.

-Tokyomage


Did you know that water is wet? - "The more you know"
jlahtinen
15
Years of Service
User Offline
Joined: 26th Oct 2009
Location: Finland
Posted: 7th Oct 2012 19:07 Edited at: 7th Oct 2012 19:09
Eh, nothing.

Login to post a reply

Server time is: 2024-11-23 09:30:42
Your offset time is: 2024-11-23 09:30:42