Jump to content


Photo

Networking - Server crashes randomly when client is outside local network.

gm:studio

  • This topic is locked This topic is locked
14 replies to this topic

#1 Pixelated_Pope

Pixelated_Pope

    GMC Member

  • GMC Member
  • 338 posts

Posted 24 June 2015 - 12:33 AM

HI all.

 

So I just started playing with networking in GameMaker, and I started working on a simple chat client/server setup to get my feet wet.  Everything seems to work fine on my local machine.  I can have several clients all connected to the server and all chatting to each other; disconnecting, reconnecting, etc.  But as soon as someone connects from outside my local network, the server becomes... unstable?  I'm not sure what causes it, but my server just crashes with no error message.  I just get the windows "Application has stopped working" message.

 

They can chat and everything, but at some point the server crashes.  I have no experience with debugging network issues, so I don't have the first clue where to start with this issue.  Any ideas?  I know there's not much info to go on, I can share my project if anybody is willing to look into it and see if they can reproduce it.


  • 0
 

D3svqFp.pngen_generic_rgb_wo_60.png

  Currently in a "beta" state.  Working on the new graphic overhaul right now!
 

#2 G-Games

G-Games

    GMC Member

  • GMC Member
  • 1130 posts
  • Version:GM:Studio

Posted 25 June 2015 - 07:22 PM

Try and see if you sometimes get invalid data when you receive data. This could cause a potential crash, depending on how you've set up your game. When starting to develop multiplayer for my game, locally it ran perfect. However, when connecting with a friend of mine who runs Windows 7, I discovered some GM:S built-in networking issues. I should totally point these out some day.

 

Anyhow, here's the list of "don'ts", and they (almost) all have to do with buffer writing (please note that all these were tested with a byte alignment of 1 and 2):

 

1) You CANNOT use buffer_u8 / buffer_s8 in conjunction with buffer_s16 / buffer_u16 / buffer_f32

2) buffer_string should always come before buffer_f32

3) buffer_f32 may only be used after buffer_s16 / buffer_u16, unless these types are unused

4) You may only send ONE packet per step, otherwise packets seem to get 'lost' every now and then

5) Using a buffer_grow, may result in not having anything work on it: buffer_fixed seems to be most stable (buffer_wrap is untested, however)

 

Have a look if any of these things mess with your networking.

 

A common thing for a tutorial is to do a sample packet like this:

 

buffer_seek(buffer, buffer_seek_start, 0);
buffer_write(buffer_u8, 0);
buffer_write(buffer_string, "Text");
network_send_packet(socket, buffer, buffer_tell(buffer));

 

This works locally, however, if you send this to someone else over TCP connection, this will not work if your buffer isn't aligned to 1. And they do not tell you this.

 

I assume the issue has to do with how Windows handles the actual buffer reading. I think Windows 8+ seems to be fine, however, Windows 7 and down seem to handle buffers differently, which could cause severe reading issues.

 

Test if your friend can host the game locally without it crashing. If it does crash, this is a sign it's because of your friend's pc.

 

That should be all advice I can give you right now!


  • 3

#3 Pixelated_Pope

Pixelated_Pope

    GMC Member

  • GMC Member
  • 338 posts

Posted 25 June 2015 - 07:43 PM

Awesome.  Thank you so much.  That gives me lots to look at.  First things first: what OS is my friend using...


  • 0
 

D3svqFp.pngen_generic_rgb_wo_60.png

  Currently in a "beta" state.  Working on the new graphic overhaul right now!
 

#4 Juju

Juju

    GMC Member

  • GMC Member
  • 1109 posts
  • Version:Unknown

Posted 28 June 2015 - 11:34 AM

Nice summary G-Games. Anything else we should be aware of?


  • 0

Come find me @jujuadams

 

Try out my open-source 3D globe terrain generator!

How about a fancy-pants text engine?

Adding dialogue boxes to your games is now super easy. Also localisation. Also tweening.


#5 G-Games

G-Games

    GMC Member

  • GMC Member
  • 1130 posts
  • Version:GM:Studio

Posted 28 June 2015 - 06:15 PM

Nice summary G-Games. Anything else we should be aware of?

 

There might be a couple of more things that I've missed, however, I forgot. I'd love to hear more from people about things they've discovered or issues they've come across (especially from Mac users, as I don't develop for Mac (yet)).


  • 0

#6 Juju

Juju

    GMC Member

  • GMC Member
  • 1109 posts
  • Version:Unknown

Posted 31 December 2015 - 05:00 AM

There have been a fair few new versions released since this post was made. Can you run your tests again G-Games?


  • 0

Come find me @jujuadams

 

Try out my open-source 3D globe terrain generator!

How about a fancy-pants text engine?

Adding dialogue boxes to your games is now super easy. Also localisation. Also tweening.


#7 G-Games

G-Games

    GMC Member

  • GMC Member
  • 1130 posts
  • Version:GM:Studio

Posted 01 January 2016 - 12:11 PM

As far as I'm aware right now, some of the mentioned issues have been resolved. I won't be able to test on Windows 7 anymore, since everyone I know has upgraded to Windows 10 now.

 

Number 1 and 4 still seem to be present, however.

 

1) You CANNOT use buffer_u8 / buffer_s8 in conjunction with buffer_s16 / buffer_u16 / buffer_f32

...

4) You may only send ONE packet per step, otherwise packets seem to get 'lost' every now and then

 

Reason 4 is completely legit, and is simply stupid coding practice. You can send multiple packets after each other if you can't do anything else, as long as you try to limit it as much as possible (in one step only, two/three/four packets at once would be no real problem, for example).

 

I still can't figure out why the reason 1 occurs, but I assume it has something to do with incorrect byte alignment. I have zero clues as to why this happens, but the issue occured most of the time when using a buffer_grow, so I'd simply recommend avoiding those, and picking a simple buffer_fixed with proper alignment (1 or 2). That has worked best for me in the past.

 

Anyhow, the original problem lay in Windows 7 (as far as I'm aware), and with that out of the picture, almost everything is automatically resolved. That's all I can say here.


  • 0

#8 GameGeisha

GameGeisha

    GameGeisha

  • GMC Member
  • 6565 posts
  • Version:GM:Studio

Posted 01 January 2016 - 08:21 PM

I still can't figure out why the reason 1 occurs, but I assume it has something to do with incorrect byte alignment. I have zero clues as to why this happens, but the issue occured most of the time when using a buffer_grow, so I'd simply recommend avoiding those, and picking a simple buffer_fixed with proper alignment (1 or 2). That has worked best for me in the past.

 

It's most definitely a byte alignment issue.

 

You said that you tested this under 1- and 2-aligned buffers and got inconsistent behaviours. But if you know that u8 and s8 are 1-byte and s16, u16 and f32 are 2-, 2- and 4-byte respectively, it's pretty obvious why the behaviours are inconsistent. In a 1-aligned buffer, u8 and s8 retain their original size, but in a 2-aligned buffer, they have to be padded to 2 bytes. If you send a 2-aligned buffer and it becomes interpreted as 1-aligned in the recipient, the reading frames would get completely thrown off.

 

This is the reason why buffers used for networking should always be 1-aligned. If any padding is necessary, it must always be done manually and implemented on both the sender and the recipient.

 

GameGeisha


  • 2
Latest Releases:
  • GMLinear --- Matrix and vector math in one line!
  • GMAssert --- Debug invalid values and write quick unit tests with ease!
  • KameGMS --- Bring up TortoiseSVN and TortoiseGit dialogs from within the GMS IDE!
  • JSOnion v1.1 --- The stink-free way to handle JSON! (even deeply nested ones)

#9 Loaf

Loaf

    Just loafing around

  • GMC:Member
  • 2164 posts
  • Version:GM:Studio

Posted 19 January 2016 - 10:57 PM

As far as I'm aware right now, some of the mentioned issues have been resolved. I won't be able to test on Windows 7 anymore, since everyone I know has upgraded to Windows 10 now.

 

Number 1 and 4 still seem to be present, however.

 

1) You CANNOT use buffer_u8 / buffer_s8 in conjunction with buffer_s16 / buffer_u16 / buffer_f32

...

4) You may only send ONE packet per step, otherwise packets seem to get 'lost' every now and then

 

Reason 4 is completely legit, and is simply stupid coding practice. You can send multiple packets after each other if you can't do anything else, as long as you try to limit it as much as possible (in one step only, two/three/four packets at once would be no real problem, for example).

What do you mean with number 1? Do you mean making a packet with both u8 and u16 for example, or mixing signed and unsigned? I've only tested on OS X and Windows 8 but I've never had a problem mixing unsigned types.

I also don't have issue 4 with my game either. I don't make a habit of sending multiple packets in one step but on one occasion it sends about 4 or so without complaint. I've tested the game thoroughly by using a program called clumsy and simulating a bad network with high latency and missing / mixed up packets, and the game has never glitched out.

How did you come to your conclusion? Can you be certain it's not a bug in your code?


Edited by Loaf, 19 January 2016 - 10:58 PM.

:duck:


#10 G-Games

G-Games

    GMC Member

  • GMC Member
  • 1130 posts
  • Version:GM:Studio

Posted 20 January 2016 - 05:54 PM

Do note that I'm testing with a server Windows 10 and a client Windows 7. And that last OS version seems to have some really annoying issues when it comes to networking on GM:S.

 

Also, as GameGeisha pointed out earlier on, it may also have been an incorrect buffer alignment. I always use an alignment of 1, and whenever you mix a buffer_u8 with a buffer_f32 within that alignment, you get errors. Using a greater alignment, buffer_u8 will return incorrect values (without adding "empty bits" manually).

 

The latter seems the most logical to me, however, I must admit I'm not 100% sure.

 

Point 4 has to do with lots of packets at once. Go ahead and send 100 packets after each other within one step. Half of them will get lost, no matter how good your networking is. As I mentioned, two, three or four packets at once should be no big deal (and you could probably go a bit over that), but once you start getting into the realm of loads of packages each step, you'll start to lose some of them.

 

Hopefully that has answered your questions fully.


  • 0

#11 Juju

Juju

    GMC Member

  • GMC Member
  • 1109 posts
  • Version:Unknown

Posted 21 January 2016 - 11:40 PM

 

Go ahead and send 100 packets after each other within one step.

Is that 100 packets through the same socket or 100 packets spread across many sockets?


  • 0

Come find me @jujuadams

 

Try out my open-source 3D globe terrain generator!

How about a fancy-pants text engine?

Adding dialogue boxes to your games is now super easy. Also localisation. Also tweening.


#12 Loaf

Loaf

    Just loafing around

  • GMC:Member
  • 2164 posts
  • Version:GM:Studio

Posted 22 January 2016 - 12:16 AM

Thanks for the info G-Games, I don't send that many packets per step thankfully.
 

Do note that I'm testing with a server Windows 10 and a client Windows 7. And that last OS version seems to have some really annoying issues when it comes to networking on GM:S.

 

Also, as GameGeisha pointed out earlier on, it may also have been an incorrect buffer alignment. I always use an alignment of 1, and whenever you mix a buffer_u8 with a buffer_f32 within that alignment, you get errors. Using a greater alignment, buffer_u8 will return incorrect values (without adding "empty bits" manually).

 

This worries me a bit. As above I've only tested in 8.1 and OS X, haven't tried 7 or 10. I also have an alignment of 1.

I just did a check over my code and I'm only using a combination of unsigned values and strings, so maybe that is why I've had no issues?


:duck:


#13 G-Games

G-Games

    GMC Member

  • GMC Member
  • 1130 posts
  • Version:GM:Studio

Posted 22 January 2016 - 11:08 AM

 

 

Go ahead and send 100 packets after each other within one step.

Is that 100 packets through the same socket or 100 packets spread across many sockets?

 

 

Through one socket, that is. It's way too much, and it makes sense for packets to get lost within the stream (especially with bad internet connections).

 

Thanks for the info G-Games, I don't send that many packets per step thankfully.
 

Do note that I'm testing with a server Windows 10 and a client Windows 7. And that last OS version seems to have some really annoying issues when it comes to networking on GM:S.

 

Also, as GameGeisha pointed out earlier on, it may also have been an incorrect buffer alignment. I always use an alignment of 1, and whenever you mix a buffer_u8 with a buffer_f32 within that alignment, you get errors. Using a greater alignment, buffer_u8 will return incorrect values (without adding "empty bits" manually).

 

This worries me a bit. As above I've only tested in 8.1 and OS X, haven't tried 7 or 10. I also have an alignment of 1.

I just did a check over my code and I'm only using a combination of unsigned values and strings, so maybe that is why I've had no issues?

 

I'm not 100% sure what happens "behind the scenes". These are just the things I've experienced and they may differ per OS. For example, I have no information regarding OS X / Ubuntu networking.

 

Windows 7 is practically obsolete now for most users. The only people who use Windows 7 now are people who still have a rather old pc, and are, really, really fond of that OS. Most people who buy a new PC get Windows 10, and since the upgrade was free, a lot of people already have this version. I shouldn't worry too much about Windows 7 issues anymore, however.

 

buffer_u8 and buffer_string can all run with an alignment of 1, so if you've been combining those, you should be fine. buffer_u16 and buffer_u32 sometimes don't cause problems, but I'm not sure why / why not, however, buffer_f32 almost always seems to end up as an issue (without proper alignment).

 

Buffers are really finicky things, and it's all about alignment in order to send them correctly.

 

Note that I'm still no expert on the subject. Someone who knows a lot about this stuff (bit alignment, etc.) could probably clarify a lot of things here.


  • 0

#14 Braffolk

Braffolk

    Lumenus Team

  • GMC Member
  • 1010 posts
  • Version:GM:Studio

Posted 03 February 2016 - 11:23 PM

This is a bug in GM itself. What G-Games suggested does work but it's too much hassle, that would also only solve the problem for users that don't have a slow internet connection.

 

This was reported awhile ago and YoYoGames claims it was fixed in the latest beta, but it wouldn't really be the first time that it's only partially fixed.

http://bugs.yoyogame....php?id=0019800

 

The best way to fix this is to have 2 separate sockets, one for receiving data and the other for sending data. This will stop packets from conflicting with each other and creating junk data.


  • 0

xOVkpik.png

Custom sprite framework(GML): http://gmc.yoyogames...howtopic=669935

My main project ^o^ 2Volution GMC | GameJolt


#15 Loaf

Loaf

    Just loafing around

  • GMC:Member
  • 2164 posts
  • Version:GM:Studio

Posted 04 February 2016 - 12:03 AM

This was reported awhile ago and YoYoGames claims it was fixed in the latest beta, but it wouldn't really be the first time that it's only partially fixed.
http://bugs.yoyogame....php?id=0019800


This topic predates the fix, so hopefully it should be fine now.

:duck:






Also tagged with one or more of these keywords: gm:studio