[Nutu_]

hi there, so i saw somewhere that in like 5,6 servers (community servers) you've got the same amount of cash ($), and there weren't like round money, kill money (by default of cs).. you just got to do some jobs (depents on the mode) do gain money! If you've done like 50$ on first server, if you connect to second server, you have 50$ as well and so further!
1. How to make that? "connecting" two servers plugins?
2. Does anyone knows a plugin that do that with money? like, more than 16000, no rounds money, start money, etc (smth like all in one, money management) because i've searched before but didnt found, just for each but couldn't merge them
thank you!

[bigdaddy424]

mysql?

[Bugsy]

You just need the ability to allow the servers to communicate with each other, or access the same database/files. An SQL server would be the simplest.

You could also handle this with sockets. One game server could also function as the data server for the other plugins/servers. UDP transactions I think would be pretty simple. Assume server 1 is the primary..server 2 connects, sends server 1 the players steam id, and server 1 responds with their money. When disconnecting from server 2, send server 1 the new money amount. Server 1 handles all data saving using nVault, or something

[fysiks]

(My)SQL is certainly the best option here.

UDP is an unreliable mechanism for data transfer so you might lose data. If the servers on are the same machine, might not be as big of an issue but you still have to build and maintain your own plugin-based database and communication protocol.

[Bugsy]

Agree, UDP isn't ideal, but probably enough for this. There can be an acknowledgement system where a client sends the server a request and if no response is received after an interval, re-send. There would be an issue when a client disconnects and his 'new' money value is transmitted but not received by the server, it'd be forgotten.

[fysiks]

You just described TCP, basically. Though not sure if TCP adds much delay to the thread execution.

[Bugsy]

Yeah, that's where my head was at, I think UDP is more simplistic as you do not need to establish a formal connection, assuming this is more efficient. The game itself runs on UDP packets, so it has to be relatively reliable.

[Nutu_]

thank you for your answers! gonna learn more about mysql

[HamletEagle]

Originally Posted by Bugsy Yeah, that's where my head was at, I think UDP is more simplistic as you do not need to establish a formal connection, assuming this is more efficient. The game itself runs on UDP packets, so it has to be relatively reliable.

Games, in general, run on UDP not because it is relatively reliable, but because TCP is a terrible idea in this case. TCP must maintain the order of packets so for example, if packets 1,2,3 are received, packet 4 is lost and packets 5-1000 are received, packets 5-1000 will be held back until it receives packet 4 which can really disrupt gameplay. Imagine freezing the entire game because one meaningless packet was lost. This is a big no-no.
Moreover, games have advanced prediction algorithms on the client which can account for a few lost packets.

UDP is not reliable, at all, but this is by design. UDP sends the packet and after that, you are at the mercy of the network. If something goes wrong, tough luck. UDP won't assist in any way.
The question is about the reliability of the network(not UDP) and you can not make any assumptions about that. There are 2 choices:
-you need reliable communication: use TCP
-you are fine with losing packets from time to time(for example a video player, a game, etc): use UDP

Long story short, TCP does way too many things to maintain a stable communication channel which can end up hurting the game experience way more than it helps.

Delaying the main thread is also irrelevant, never run blocking calls in the main thread. Use threaded/asynchronous calls and delegate the work to a worker thread.
See threaded sockets module.

If the servers are on the same machine then there shouldn't be any packet loss using UDP as the packets will be routed locally thru the loopback interface, no potentially unstable network to mess with your packets.