151 replies to this topic

[sabriath]

I can't see why not. It just saves finding the instance. The instance itself runs the code.

Yes, that would work fine, I haven't looked at my work in a long time.

ds_map

This tutorial is based on the idea that the server's objects are more important than anything. This means that all client objects must create their objects and somehow relate the server IDs to the client IDs (when the server creates an object, GM gives it an ID...when the client is told to create an object, those IDs will more than likely not match).

A ds_map gets rid of this problem by associating one number with another. Each 'key' associates with a 'value' (and we won't get into the specifics of having multiple copies of the same key), and so when the server tells a client "hey, I just created object 'butterfly' and it's ID is 100048"...the client will then create a 'butterfly' object and associate '100048' with whatever ID is given from 'instance_create'. When the client or server need to communicate about a specific object in the game world, they BOTH will use the server's ID values. This ensures that they are "looking at" the same object.

You can read the help file for all the ds_map_* functions.

[fireblade212]

what does each case do?

[Sparkyboy734]

Wait, how did the people get hamachi to work? :S
I can live with hamachi but it doesnt connect.

[chrismaster]

You know, I'm not sure if this is the best place to ask, but there's one thing I've always wondered. Why can't I just, instead of forwarding, tell the router in the package header to which internal IP I want it redirected? If I know both the address of the router and the internal IP of the PC behind it I want to reach, why should the PC I want to reach forward the port in the router instead of letting me tell the router to which PC I want the package to go?

[sabriath]

You know, I'm not sure if this is the best place to ask, but there's one thing I've always wondered. Why can't I just, instead of forwarding, tell the router in the package header to which internal IP I want it redirected? If I know both the address of the router and the internal IP of the PC behind it I want to reach, why should the PC I want to reach forward the port in the router instead of letting me tell the router to which PC I want the package to go?

Security

Imagine a basic company server cluster behind a router, and we'll also assume it doesn't have ISA. In this situation, all outgoing traffic is marked in a NAT list in the router so that when a reply is sent back, the router knows where it's going. Any outstanding incoming traffic is ignored because no one asked for the data. Now imagine a "hacker" sending random internal addresses bypassing the router pretending to be another internal computer...the computer gives up any vital information because it thinks it's inside the network.

This is bad.

Think of it like the postal service. The router is the person in your house who goes through the mail looking at the names and handing it out to the family members it belongs to...any mail that doesn't belong gets thrown away. In the same analogy, being able to bypass this is like the postman kicking down your door and grabbing the first person who moves and forcing them to read a letter that doesn't belong to them.

If you don't tell someone who you are and where you live, they cannot address you properly, just like internet.

Now look at it on the side of the server, who actually wants a specific port to make it through. But again, the server needs to be secure...just because you want a person to come into your home, doesn't mean you want him to walk into your bedroom and steal your checkbook. You have to tell the household member that "if any of my friends come here, let me know." This is telling the router which computer in an entire network to send traffic to.

Also, let's say that the computer that is handling all incoming traffic crashes, what do you do? An expert would simply run the server on a different computer in the network and all is good....however, the new computer might have a different IP address. In your situation, the game clients have NO idea about this new computer's internal IP address. Players are trying their hardest to connect to the crashed computer because that's the only internal IP address they were given right? In a normal situation, all server maintenance has to do is change the portforwarding address to the new computer and done. Not only is your situation insecure, it is not possible with current technology, nor wanted.

Portforwarding is only needed by the server, and takes literally 20 seconds to do....there is no excuse.

[chrismaster]

Thanks for the explanation =)

[spasbunny]

Hi, just a question regarding port forwarding...

I currently have a server program which tracks all statistics, keeps tabs on who is currently online and keeps track of basic game information for each session, as well as a client program that logs in and then has the choice to either host a session or join a session being hosted by someone else. While I know that the master server will require port forwarding, I was hoping that I would be able to avoid users needing to port forward. Unless I'm missing something here then the game host will have to have the required ports forwarded in order for other players to connect to each other. Is there some trick to avoid this?

[sabriath]

Unless I'm missing something here then the game host will have to have the required ports forwarded in order for other players to connect to each other. Is there some trick to avoid this?

Since you do not have direct control over the socket creation, you are unable to do simultaneous TCP connections which would normally TCP holepunch the routers. The only methods left are to use UDP holepunching and create your own reliable UDP connection protocol, do all network traffic through the main server as a relay, or require that any computer that wants to host has to portforward.

[spasbunny]

Since you do not have direct control over the socket creation, you are unable to do simultaneous TCP connections which would normally TCP holepunch the routers. The only methods left are to use UDP holepunching and create your own reliable UDP connection protocol, do all network traffic through the main server as a relay, or require that any computer that wants to host has to portforward.

Just to clarify, does this holepunching method involve both clients initiating simultaneous connections over the same port in order for network traffic to be automatically redirected to either target computer by the router? You then mention that while UDP holepunching is possible, TCP holepunching is not due to the need for direct control over the socket. Is this just the way of things due to something like TCP handshaking, or is it because the dll simplifies the whole process and removes some options that would allow for it?

Thanks for the quick reply

Edited by spasbunny, 26 September 2011 - 07:11 AM.

[sabriath]

Just to clarify, does this holepunching method involve both clients initiating simultaneous connections over the same port in order for network traffic to be automatically redirected to either target computer by the router?

yes

You then mention that while UDP holepunching is possible, TCP holepunching is not due to the need for direct control over the socket. Is this just the way of things due to something like TCP handshaking, or is it because the dll simplifies the whole process and removes some options that would allow for it?

Because "tcp_connect" creates a bare "any_port" socket and uses the socket "connect" command which the system will then assign it a port for incoming traffic after already sending the "SEQ" packet. I am not sure if you can get the port of the socket before a connection is made, but the socket will probably timeout before you have a chance to relay it...and the port will be lost. UDP however requires you to enter a port for incoming transmission (it acts like a "listen" that you are able to send data out of), this gives you the ability to send data between the 2 computers simultaneously in order to open a port through the router.....but UDP is unreliable, so you'll have to build a reliability on top of it.

The other option is to look at the 39dll sourcecode and make your own function that gives you more socket control. A tcp_connect_with_port function or something that lets you assign it a port before "connect" is called. You can then relay to the client and subserver each others IP:Port information and that will create a simultaneous connection.

[darthrevan]

So in order to release an online game you have to keep the sever.gmk open all the time? or the game won't work?

[spasbunny]

Because "tcp_connect" creates a bare "any_port" socket and uses the socket "connect" command which the system will then assign it a port for incoming traffic after already sending the "SEQ" packet. I am not sure if you can get the port of the socket before a connection is made, but the socket will probably timeout before you have a chance to relay it...and the port will be lost. UDP however requires you to enter a port for incoming transmission (it acts like a "listen" that you are able to send data out of), this gives you the ability to send data between the 2 computers simultaneously in order to open a port through the router.....but UDP is unreliable, so you'll have to build a reliability on top of it.

The other option is to look at the 39dll sourcecode and make your own function that gives you more socket control. A tcp_connect_with_port function or something that lets you assign it a port before "connect" is called. You can then relay to the client and subserver each others IP:Port information and that will create a simultaneous connection.

I'm quite new to the whole networking thing, and so while I'm vaguely familiar with SYN, ACK, SYN/ACK and FIN packets I haven't come across mention of 'SEQ' packets yet.
Also, while I acknowledge that this would be a very ugly technique, wouldn't both sides spamming TCP connection attempts on both sides result in at least a few getting through before the timeout? Or is the timeout triggered by the type of packet being received as opposed to a set time period?

So in order to release an online game you have to keep the sever.gmk open all the time? or the game won't work?

The server acts as a point where all the information goes before it is sent out to other clients, so no server means no communication between the clients. Unless you are happy to make your users find out and type in the IP address of everyone they want to connect to, you need the server to act as a go between.

Edited by spasbunny, 27 September 2011 - 05:21 AM.

[sabriath]

So in order to release an online game you have to keep the sever.gmk open all the time? or the game won't work?

That's like saying "blizzard has to keep their servers on all the time in order for you to play online?" Yes...if you want online games to work, it's obvious that you need a server to run it. I do not know who teaches these ideas that internet communications are blasted to everyone's computer at the same time or something...as if everyone can talk to everyone without needing IP addresses....this is false.

I'm quite new to the whole networking thing, and so while I'm vaguely familiar with SYN, ACK, SYN/ACK and FIN packets I haven't come across mention of 'SEQ' packets yet.

I'm sorry, you're right...SYN is what I meant to say, I knew it didn't look right but just let it slide anyway.

Also, while I acknowledge that this would be a very ugly technique, wouldn't both sides spamming TCP connection attempts on both sides result in at least a few getting through before the timeout? Or is the timeout triggered by the type of packet being received as opposed to a set time period?

What I meant is that when you run "tcpconnect" it fires a SYN packet immediately using a Windows assigned port (assumed random). I just looked at the scripts and actually cannot find a script to get the port of the socket...so this option is off the table completely. You will either need to use UDP or create your own function in 39dll, sorry.

[spasbunny]

I'm sorry, you're right...SYN is what I meant to say, I knew it didn't look right but just let it slide anyway.

What I meant is that when you run "tcpconnect" it fires a SYN packet immediately using a Windows assigned port (assumed random). I just looked at the scripts and actually cannot find a script to get the port of the socket...so this option is off the table completely. You will either need to use UDP or create your own function in 39dll, sorry.

I think I'll have to go with UDP for in game data then, maybe get the chat lobby to be relayed through the main server... I'll probably have to push out a TCP only version first though, I'm designing the multiplayer aspect for a friend who needs it soonish and I have a feeling that writing my own data correction will take too long. After that I guess I can start looking at UDP, which I should probably be using anyway.
Either way, thanks for your help. You've managed to make someone with no clue feel relatively comfortable about designing multiplayer games, no mean feat

[Hello-World]

I am having the hardest time trying to get the game to load player names. Can someone give me the basic idea of how to achieve this?

[Mr. Guevara]

I'm at 'round chapter 10 - 11 and i bumped into something that's probably really simple but i've just missed as always. Starting the server and several clients results in every client just showing one player, nobody else. I even tried it with the example files and even those didn't seem to work. I'd describe the problem more clearly if i could, but the only thing i can tell you is that the clients only see themselves.

Regards,
Your average 39dll newb

[peoplethought]

In a reply you say that clients should only send messages to the server then the server checks to see if it's correct. So clients can't change any values like their x,y on their own. They have to ask the server to do it for them, then the server relays the information back to them? If so, the code you put in that tells clients to ignore information mirrored back to them from the server would cause this information to be ignored.


Also, that code that tells clients to ignore their own information being sent to them - would it not be more efficient to just not send clients their own data to begin with (assuming we aren't doing it by asking permission from the server to make changes like I say above)? This would require a different packet to be put together for each client though.

Edited by peoplethought, 28 October 2011 - 05:06 PM.

[Ruub]

nice bookwork. Nice website!

Now go finish your new DLL :@ (start by making it gm8.1 useable)


EDIT:

wauw, I read the chapters. and I learned

Though I still have some important questions:

-Is it possible to let players join without having to port forward (so you can make other people who are lazy be their own server -> so their servers can connect to your server and you can support a lot more players)
-Is it possible to let the server be run on a website, if so.. is this smart? yes? Please explain why.
-If there is lag in an action game, what is the best way to deal with this? (make the game predict things? solve subtle (no teleport but moving towards example))
-Any optimalisation tips excep for using the right packages?

Edited by Ruub, 03 November 2011 - 05:31 PM.

[sabriath]

Mr. Guevara: Everyone has problems with that area, Chapter 11 simply makes the server tell the clients that there are other people connected....Chapter 12 is the clients actually SEEING other people. You'll need to move on to Chapter 12 and finish that first.

peoplethought: Yes and no. The client can do a lot of the things itself, like move the character and display the surroundings....however, the server gets the ultimate choice on whether the client is allowed to move or not. This is part of dead-reckoning and advanced techniques, exceeding this tutorial. For now, the reason the client is ignoring its own data relayed back is because you don't want a ghost image to appear. If you want the server to FORCE the client to move to a specific spot, you should add in a "force move" command byte (for the network communication and switch block). Also, the server currently (in this tutorial) sends everyone's position to everyone at every step, this is way too much bandwidth wasted...again, this was only a tutorial to get you started.

Ruub: thanks

1. Whatever computer is acting as the server requires portforwarding if its behind a router, there's no workaround for this. This is done by design for security and ease (and yes, it's actually easier to do it this way).
2. A website doesn't "run" anything, unless the host offers server-side code ability (php for example), so this route is not the best way to do it.
3. Dead-reckoning
4. Too many to put in a short period of time, some of the areas that I thought needed optimized were built into net39...so you can check out the source and see for yourself (although it's not the best), and keep up with the slow progress of it for more.

[darthrevan]

Question are you able to make a lobby were you can watch a match going on or is that too much?