Jump to content

  • Log In with Google      Sign In   
  • Create Account

hplus0603

Member Since 03 Jun 2003
Offline Last Active Yesterday, 08:12 PM

#5286483 Bandwidth cost inside the datacenter

Posted by hplus0603 on 12 April 2016 - 09:52 AM

If you go with co-location, and put your own hardware in, then you have your own switches/routers at the top of each rack, and your own Ethernet cables (that you have to neatly arrange yourself.)
At that point, no, the only cost is usually space and power/cooling, plus whatever access/transit you have to pay to get out of the place.

If you use a cloud/VPS provider, the policy varies by provider. Amazon will typically charge you for transit between availability zones, but not charge for traffic withing availability zones. They may have multiple AZs in the same approximate physical location, though, so make sure you consider this when choosing instance location.
Cheaper providers will just measure by host/instance, and apply a cap, and charge you if you go over. Some also provide two interfaces, one local (10.x or whatever) and one routed, and charge the routed interface traffic.


#5286160 Should I use multithreading for sending messages?

Posted by hplus0603 on 10 April 2016 - 11:19 AM

In general, there is very little overhead on a modern computer to recv/send in the main thread. Even processing/serializing the messages is unlikely to ever show up on a profiler for a typical game client protocol.
Note that send() just copies data from your buffer into an "outgoing buffer" in the kernel, and recv() just copies already-received data from the kernel "incoming buffer" into your buffer.
Thus, a reasonable client implementation could look something like:

while (running) {
  int r;
  sockaddr_in addr;
  socklen_t asize = sizeof(addr);
  while ((r = recvfrom(sock, buf, sizeof(buf), MSG_DONTWAIT, (sockaddr*)&addr, &asize)) > 0) {
    process_incoming_packet(buf, r, addr);
  }
  read_user_input();
  perhaps_update_simulation();
  render_graphics();
  if (now() - last_sent_time >= send_interval) {
    last_sent_time = now();
    r = form_outgoing_packet(buf, sizeof(buf));
    if (r != sendto(sock, buf, sizeof(buf), 0, &serveraddr, sizeof(serveraddr))) {
      error();
    }
  }
}
This sketch assumes UDP. TCP is slightly different, as you need to separate out your own packet boundaries and retain what's left in the buffer between reads.

Anyway, in games, the physics simulation, graphics rendering, perhaps audio, and sometimes the AI, may benefit from separate threads, but networking generally doesn't.
If and when it does, you'll want one single thread for networking, and have a well-defined (and well tested!) communication mechanism between that thread and the threads that need the data.

Threads help in one of two cases:
- you do computation that has well-defined input and output dependencies to the rest of the program AND that computation takes "significant work" (milliseconds or more.)
- you have some event that needs absolutely lowest latency (such as VR scanline-chasing rendering, or audio generation) and run the thread at real-time priority

Threads are sometimes also added to work around cases where proper asynchronous I/O is not available, such as reading from files on Linux. You can build a worker thread that accepts "read file" requests, and posts results back to whoever started the request when done. This isn't needed for networking, because non-blocking or select-based or event-based socket I/O is sufficiently asynchronous.


#5286156 [ANSWERED] Questions about public WiFi vs private WiFi

Posted by hplus0603 on 10 April 2016 - 11:05 AM

Stickied.


#5285664 [ANSWERED] Questions about VPN for server hosting

Posted by hplus0603 on 07 April 2016 - 05:18 PM

Also, Steam doesn't host the "game servers" for you; it only hosts the "matchmaking" and "social" servers for you.
If you still need gameplay servers, you will have to host them yourself, and use Steam to let players know which servers are up.
If all you need is matchmaking (two players talk to each other) then Steam is sufficient for making the players find each other, and you no longer need your own server unless there is a non-Steam version.


#5285362 Syncing Client/Server

Posted by hplus0603 on 05 April 2016 - 06:02 PM

You need the map of "last version seen" per connected client.
Then, when time comes to update clients, iterate over the data you have, and compare to the versions seen by each client, and send data that the server has a newer version of.
If the client could miss the update (crashing, dropped packets, or whatnot) then it makes sense to have the client send the last version number it's seen, rather than the server just assuming the client sees everything it sends.


#5285075 http request onto https service

Posted by hplus0603 on 04 April 2016 - 01:35 PM

HTTPS is served (typically) on port 443, and HTTP is served (typically) on port 80.
If you send the wrong kind of data to a particular server, it will detect a protocol violation and send an error back.
It is very common to run both HTTP and HTTPS servers on the same domain. In the best of worlds, the HTTP server simply does a permanent redirect to the HTTPS version of the same resource for GET/OPTIONS/HEAD, and returns an error for POST/PUT/DELETE. Although some servers accept the same requests on HTTPS and HTTP, for legacy or simplicity reasons.

You also seem to believe that a HTTPS server needs to be "certified" and is somehow more secure than a HTTP server.
This is not true. A HTTPS server does need a signed certificate (which is a data file) to be able to properly identify itself to clients that connect, so that the client can known that the server on the other end actually is "citibank.com" like in the URL, and not "myversionofcitibank.com."
However, there is no security or operational differences in the hardware/software actually running on the machines.
The only difference is that HTTPS makes it harder to read the data while it's on the wire (if you can read packets on the wire,) and also makes it harder to pretend to be a domain you aren't authorized for (if you can hijack DNS somehow.)
Something (bugs, bad code, etc) that's insecure on the client when using HTTP, is still insecure when using HTTPS.
Something (bugs, bad code, etc) that's insecure on the server when using HTTP, is still insecure when using HTTPS.

Btw: You can now get free HTTPS certificates for your domain by jumping through a very small amount of hoops.
Check out letsencrypt.org!
(Some hosting providers even have a checkbox to do this for you; such as DreamHost)


#5285037 Game Analytics - What tools should i use?

Posted by hplus0603 on 04 April 2016 - 10:39 AM

There are tons of solutions and providers, with a variety of levels of sophistication.
They can all do simple things like "DAU" and "MAU" and "RPU" and "conversion rate," which are all great first-line metrics.
Most of them can do simple correlations, like "players with event X convert better than players with event Y." Events kinds are typically defined by you.
I've found that, once you reach the point where you want a little more sophistication (identifying and comparing common paths; recommending next actions to users; that kind of thing) then you either have to pay serious money to some provider, or pull it in-house.

Depending on how big your game is, you can fit it all in a single database (Postgres, MySQL, or whatever,) or you'll need to talk to the elephant. Single database is VASTLY preferrable.
Or pay big money to something like Google Big Table or Amazon Redshift.
(There are other providers; I'm not gonna name or shame any, but there once was this one web analytics package that cost my employer > $200k per year, and I spent two weeks of coding and we could cut them off...)

One thing to think about is whether you want to tie your analytics to your acquisition provider (buying web ads, mobile ads, etc), to your monetization provider (selling google ads, facebook ads, etc) or your platform provider (if you live on something like Parse, R.I.P.)
Choosing an analytics package that integrates well with your engine often seems like a good idea from ease of implementation, but it turns out that even the hard ones are easy to implement -- you need to identify your game to some SDK, you need to identify the user using some username/id, and you need to insert "X happened" calls in your code.
The real differentiation comes on the back end; what analysis do you get; how do you get access to your data if you want to take it elsewhere; how long do they keep your data; etc.

Unity Analytics? Mostly Harmless, somewhat useful, probably not enough once you have a real, working business.

As with everything else, though, details matter, and making sure you really do understand your requirements up front is important.
If you haven't done web and acquisition and monetization analytics before, you're unlikely to know what you ACTUALLY need, so be prepared to change horses once you learn more.


#5284822 How can I open my game to lan?

Posted by hplus0603 on 02 April 2016 - 10:41 PM

Yes, if you use the Unity engine, then using the Unity network library will likely work okay for you.
Make sure you read the overview and understand what it can, and cannot, do for you out of the box, and if you need something it doesn't do, make sure you actually know how to extend it, or you may run into surprised.


#5284630 "Weapon Fired" Event -- Reliable, Unreliable, or In-Between?

Posted by hplus0603 on 01 April 2016 - 11:29 AM

Is there a smarter way to do this?


You could assume that everything will deliver, and just pack more events in, with a sequence number.
On the client side, if you've seen reliable event X, only apply reliable event X+1 -- if you see anything higher sooner, send a NAK back to the server.
Then, the server re-starts the stream from X+1 when it gets the NAK.
The server still needs a backlog of pending messages, and an ACK to know that the messages can be removed.

You can then split reliable messages across different channels, where it's OK to re-order messages between channels, if you want more flexibility.


#5284499 Tasks to have multiplayer in your game

Posted by hplus0603 on 31 March 2016 - 10:23 AM

I'll do it for three million dollars. Might be less, depending on complexity and platforms.

The best way to get where you want to go, is to build the game using an engine that already supports multiplayer, and then use the platform for matchmaking.
So, for example, if you build your game on the Unreal Engine 4, and then host on SteamWorks or Xbox 1 or PlayStation Network or Google Play or Apple Game Center, then you can use the built-in multiplayer support of Unreal, and the built-in match-making of the platform.
There's still work to be done (your game loop/activities must know that things happen on the network) but it's much, much easier than building it from scratch, or trying to add it to an existing game in some engine that doesn't support multiplayer.

To get a flavor for what multiplayer development is like on Unreal Engine, check out these video tutorials:
https://www.youtube.com/playlist?list=PLZlv_N0_O1gYwhBTjNLSFPRiBpwe5sTwc
Even if you're not interested in Unreal Engine in particular, it may give you a bit of the flavor of the tasks.
Note that this tutorial only goes through the "what you should do" once -- you then have to do that for each and every thing in your game (anything you throw, blow up, plant, ride, steer, control, in any way.)
But that's still a lot simpler than also having to build all the code that Unreal does for you under the covers.


#5284498 Authenticating users

Posted by hplus0603 on 31 March 2016 - 10:17 AM

I was speaking about classical 2fa with "what you know" (password) and "what you have" (cellphone).


As did swiftcoder. All you have to do is pop up a dialog saying "enter your code here" and you have 30 seconds to post that valid code back to the original server, and you have a valid session.
Note even SmartCards or UbiKeys are immune. (Although they are cool, and integrate well with Google app services for business.) Tell the user to "press your key token now" and they will.
The trick is in fooling the user into trusting the site and giving up whatever credentials are needed. Hence, the "social" in "social engineering."


#5284400 Joining data to bigger UDP packets?

Posted by hplus0603 on 30 March 2016 - 07:40 PM

where does the 1272 come from


The minimum fragment size for an IP packet on IPv6 is 1280 bytes. UDP uses 8 bytes for its header, leading 1272 bytes for the payload.

In UDP, the call to recvfrom() will return the exact size of the UDP packet payload (assuming your receive buffer is big enough,) so you don't need to encode that. This is in difference to TCP, which returns "some bytes" when you call recv(), and those bytes may be the end half of one packet and the beginning half of the next, so you need to implement an explicit packet framing protocol.

When you put multiple smaller game messages into a single UDP packet (which you absolutely should do!) then you have to have some way of knowing how many of those messages there are. If each message is fixed size, this is easy. If not, you'll need to encode the length of each sub-message; typically with a byte per message (as almost no individual game messages are > 127 bytes in size, and you can use the leading bit for var-int type encodings.)


#5284322 How can I open my game to lan?

Posted by hplus0603 on 30 March 2016 - 02:01 PM

If you turn on the SO_BROADCAST option on a UDP socket, and bind to a known port number, you can send and receive packets using the segment broadcast address (which is 255.255.255.255 for IPv4.)
You can then look for other programs that broadcast on whatever port you have bound. Hopefully, those will be your game, rather than some other program :-)
Using the recvfrom() function, you will receive the IP address of the host running that copy of the game, and you can talk directly to that program using that address (no need to broadcast once you've found it.)

Thus, a game server will typically "host" a game, and start broadcasting once a second a packet that starts with some known bytes (say, the name of your game) and information about the match (#players, map loaded, or whatnot.)
Clients will then listen for this packet, and when it comes in, add that possible match to the list of available games the user can choose from.
If a broadcast packet hasn't been received for a few seconds, the client UI should typically remove the match again, as that server is no longer broadcasting the availability of the match.


#5284155 "Weapon Fired" Event -- Reliable, Unreliable, or In-Between?

Posted by hplus0603 on 29 March 2016 - 07:47 PM

Another option is to always include the last N shots fired (time, pos, vel) in each packet. If one is dropped, no big deal; the next packet that makes it will tell everybody about where it started.


#5284072 Joining data to bigger UDP packets?

Posted by hplus0603 on 29 March 2016 - 09:39 AM

IPv4 routers have the option of fragmenting, whereas IPv6 routers do not. In either case, when the routers drop a packet because of MTU limitations, they are REQURIED to send a ICMP message back telling the source about the MTU limitation, so the source host can create a fragmented IP datagram to that destination for further traffic.
I'm of the impression that the market has demanded that IPv4 routers do fragmentation for a long time, and thus that is the de facto behavior.




PARTNERS