Jump to content

  • Log In with Google      Sign In   
  • Create Account

Banner advertising on our site currently available from just $5!


1. Learn about the promo. 2. Sign up for GDNet+. 3. Set up your advert!


hplus0603

Member Since 03 Jun 2003
Offline Last Active Today, 04:01 PM

#5116069 Algorithms / techniques to determine available bandwidth

Posted by hplus0603 on 10 December 2013 - 07:18 PM

The short answer is that you can't, and if utilizing bandwidth efficiently is your goal, you should use TCP.

 

The long answer is that you can use packet loss as a proxy for bandwidth, and slowly increase the bandwidth until you get a dropped packet, and then quickly throttle back. Where "slowly" means "linearly add some constant to your estimate of bandwidth" and "quickly" means "halve the estimated throughput," you will behave like traditional TCP stacks. (Main improvements in later years: quick-start, path memory, window scaling mechanisms.)

 

It's important that you behave like this (quick scale-back, slow growth) to avoid overwhelming some local choke point, or getting into extreme oscillation, when other sources of traffic are also sharing the connection.

 

If you use TCP, then set a buffer size that you're willing to live with, and keep sending on the socket. When the send blocks and/or doesn't transfer all the data, you know that the buffer is full, and thus the other end is behind compared to the speed you have been sending at.

 

Note that, when your girlfriend starts watching Netflix, or your ISP is doing router maintenance, the available bandwidth for an existing connection may quickly change!




#5114890 Lack of Articles / Tutorials on DirectPlay

Posted by hplus0603 on 06 December 2013 - 11:07 AM

The quick answer is "you probably want to use RakNet, with eNet as a popular second choice."

 

The longer answer is "game networking is so integral to how the game and simulation works, that most games end up doing something at least semi-custom," followed by all the different ways you may want or need to go custom. Connecting using TCP and sending bytes back and forth is not very hard if you're a good systems programmer -- it's how those bytes are generated on one end, and parsed and acted on on the other end, which is the real challenge.

 

The #1 take-away is that your game loop and game simulation needs to be written with networking in mind for your game to work well as a networked game, so thinking about it early is key! Sounds like you're getting there, which is good.




#5114644 A new multiplayer server list service

Posted by hplus0603 on 05 December 2013 - 11:17 AM

Given the number of questions on this forum, it is certainly something that is asked for. I've noticed that same thing myself.

 

There are a few systems out there that already try to do this, to varying degree of success. On iPhone, you get it from Game Center. On WIndows Phone, you get it through Live!. On PC, you get it from Steam, if you're integrated to that platform. There are also infrastructure-as-a-service offerings of various kinds, starting with Gamespy and going to places like Gamedonia or Parse.

 

However, it's not quite as easy as all that. For server listings to really make sense, you need to do NAT punch-through, else users can't get to servers hosted by other users. And, because TCP NAT punch-through is still hit-or-miss (60% success, perhaps,) you really need a UDP-based protocol. And that means you need an entire game networking layer for this to all work out. And when you talk game networking layers, incumbents like enet, RakNet, etc, or built-ins to various platforms (UDK, Unity, etc) have a strong pull on developers.

 

My conclusion is that the demand is mostly there from those who are just starting out and don't know how to do this, and don't have any funding to pay for a real solution. If you want to create a real solution that will actually be worked by those with funding to pay for it, it's a real, long-term, technology-heavy project, with a significantly long sales cycle and almost enterprise-like scope. Thus, I haven't personally put my time into such a project, even though I've considered it several times.

 

You may find a different angle to take, in which case, I encourage you to keep posting progress updates, as I'd be very interested in seeing someone taking on this space and succeeding!




#5113381 Lua networking libraries

Posted by hplus0603 on 30 November 2013 - 06:17 PM

If you have the source code, using a DLL versus linking statically is almost no difference -- just a small matter of makefile differences, and perhaps a different load-into-LUA routine. The amount of massaging needed should be minimal in all of those cases.




#5112814 Publicly Host SDL_net Server

Posted by hplus0603 on 28 November 2013 - 12:36 PM

The FAQ for this forum does give some pointers on "how do I host my game so that others can run it."

In general, you have to make sure that the machine that runs the server is visible to the greater internet, which generally means port forwarding from a firewall/router (in a residential setting) or some kind of hosted server.




#5112533 identifying UDP sockets, using winsock

Posted by hplus0603 on 27 November 2013 - 01:49 PM

lomateron: Your comparison will not work right. Samoth is correct: you need to understand what the address format is, and compare the proper fields (sin_port, sin_addr, for ipv4.)

If you want to support "whatever" without knowing for sure, then you need to first zero out the buffer for the address before calling recvfrom(), and then you need to use memcmp() to compare the full size you actually received. This will likely lead to more complex code than just accepting ipv4 and using that for comparison.




#5111466 xmpp for turn based game

Posted by hplus0603 on 23 November 2013 - 12:34 PM

I know of no XMPP server that bakes in the things you're talking about; you'd have to add it into some existing server by changing the server.

That's certainly possible, but at that point, you're no longer XMPP, you're some custom client and server that happen to use XMPP for transport.

In my mind, transport is the simplest problem to solve, so using XMPP (and living within the XMPP server and client libraries you choose) may cost more than it gives you.

 

The fastest way to get to where you say you want to go is probably an existing cloud service platform, such as Parse (mobile focused) or Gamedonia (game focused.)

I haven't used Gamedonia, but someone suggested it earlier in the forums, and once you can find your way to its documentation, it seems like a reasonable option.




#5111395 Is Java Socket the best option for a real time game server?

Posted by hplus0603 on 22 November 2013 - 09:24 PM

RMI is not tuned for game needs, and would probably be a poor choice.

 

Java sockets with Java nio / aio support would probably perform well, although they are known to be tricky to get to work right.

 

I know nothing about the Java Fast Socket library.




#5110536 Streaming turn-based strategy

Posted by hplus0603 on 19 November 2013 - 12:49 PM

First: Are maps randomly generated, or pre-built? If pre-built, then you can install them with the main program and download nothing.

 

If they are randomly generated, then you have two options to improve download speed:

1) Send just the seed, and re-randomly-generate the map on each device, using a deterministic algorithm.

2) Figure out a better way to compress the data.

 

Also, trying to download bulk files (such as static maps) over reliable UDP is a poor match for the technology -- this is what TCP is for!




#5109204 Android 2 player game - connecting

Posted by hplus0603 on 14 November 2013 - 11:22 AM

Yes, a quick search will give you more information ;-)

 

If you are not familiar with networked/cloud server development, I *highly* recommend using the Google services instead of trying to roll your own. A G+ sign-in is a small price to pay for getting access to infrastructure built and run by some of the best in the business.




#5108987 sento() using a binded socket

Posted by hplus0603 on 13 November 2013 - 10:23 AM

That sounds correct.

 

The flow for a UDP server is typically:

 

socket()
bind()
forever() {
  recvfrom()
  sendto()
}

 

The flow for a UDP client is typically

 

socket()
gethostbyname()
forever() {
  sendto()
  recvfrom()
}

 

In either case, the same socket is used throughout.




#5108592 get the IP adress of the bind socket WINSOCK

Posted by hplus0603 on 11 November 2013 - 07:58 PM

There are a number of non-routable interface addresses defined in IPv6, similar to 127.0.0.1 and the 10.x and 192.168.x subnets in IPv4.




#5108483 get the IP adress of the bind socket WINSOCK

Posted by hplus0603 on 11 November 2013 - 10:14 AM

and the IP is like this... 6354:: not exactly those numbers


IPv6 shortens sequences of zeros to double-colons.

if I create another application that creates a socket and sends data to that EXACT IP will it work?


If it is a routable address, and the machine is listening for connections, yes.


#5107473 Hosting Online Game

Posted by hplus0603 on 06 November 2013 - 10:44 AM

Amazon has lots of services that can make development and management convenient. Amazon can also get very expensive in a hurry if you're not paying attention.

 

If you're building most things yourself (and using open source for the rest) then the simplest option is likely a simple virtual private server to host things on. $6/month from www.interserver.net is a good candidate (there are others, including linode, dreamhost, Amazon micro instances, etc -- verify how much you'll be paying for bandwidth in addition to the server!)




#5106608 KW X-port, specular always 0.9?

Posted by hplus0603 on 02 November 2013 - 11:19 PM

I put the code on github if you want to read it: git@github.com:jwatte/kwxport

 

Here's how it calculates the specular color:

 

        matProp = theMat->GetSpecularData();
        if (!matProp) goto not_stdmat;
        matProp->GetPropertyValue(p3);
        type = matProp->GetType();
        assert(type == IGAME_POINT3_PROP);
        matProp = theMat->GetSpecularLevelData();
        if (!matProp) goto not_stdmat;
        matProp->GetPropertyValue(f);
        if (f > 0) {
          p3.x = f; p3.y = f; p3.z = f;
        }

 

 

Translation: If the specular level is 0, use the specular color, else use the specular level as grayscale. This is likely because 3ds Max has both grayscale and color options for the properties.

You could probably change it to multiply specular color with specular level instead. (Note that specular level "2" in Max comes out as "0.02" inside the application -- the UI multiplies by 100.)






PARTNERS