Online Programming
Blitz3D Forums/Blitz3D Programming/Online Programming
| ||
| Okay, I'm in a bit of a jam. I am trying to create on online game, and someone suggested to me to use UDP. I have successfully gotten this game to the LAN stage, by using the Local IPs 192.168.0.xxx to connect to the hosting PC. However, now I want to take a bigger leap, and convert to online. Exactly what IP would I use to connect to the remote hosting PC? I have gotten my remote IP from ipchicken.com , but this doesnt seem to work. I need all the suggestions/tips I can get. |
| ||
| Have you made sure that the UDP port you are using is open on the server's firewall? It also needs to be set up on the router (if there is one) to forward packets on that port to your server. |
| ||
| I disabled the firewall for the test, so that won't be it. As for port forwarding, I will double check on let you guys know. EDIT: I went in front of the router, and through Windows Command Prompt, several of my friends and I pinged each other, I could ping them, they could ping each other, but they could not ping me. I'm guessing that something needs to be changed in my modem. Any ideas? |
| ||
| OK, sorry for the double post. I went outside the router and directly into the modem, but remote computers cannot ping my IP. I think that it is because a static IP. So now I am changing my question. Is there a way to program an Internet code in Blitz that does not require a static IP? |
| ||
| It does require a static IP if you want users to connect form the internet. IP chicken seems to report my correct IP. Remember that your router probably have a firewall tool. Ping is usually disabled. I have no problem connecting to blitz apps from outside my firewall/router, so it's probably your setup. |
| ||
| So what you are saying is that there is no way in Blitz coding that I will be able to receive data packets from a Blitz app w/o a static ip? Cause I ran a test and was able to send them just fine, but I cannot receive them. I get the same result when I go in front of the router as well. |
| ||
| Well. You can use a dynamic IP, but the users would have to input a new IP each time as it changes occasionally. Do you by any chance have software firewall like the default in Windows XP that you forgot to disable? |
| ||
| No I disabled it, to tell the truth I think its my modem, I'm gonna have to look at the settings in there and see if that helps. I found something under my internet properties, would this be what you were talking about, I had disable the firewall, and this looks like the firewalls "holes" to me.  EDIT: And hence I came upon the answer, it was a router problem. The reason it wouldnt work in front of the router is b/c I need to change in Internet Connection setting to allow users to connect to my comp on the specified port. Once I change this setting on the router, I'm good to go. Thank you for all your help. :) |
| ||
| what has online programming with UDP.. udp is for lame LAN games :) |
| ||
| Umm, then you clearly have no idea what UDP is for... UDP is the standard protocol for any online action game, it's slim headers enable a very small overhead, which is very VERY important when dealing with the internet, which is incredibly slow compared to a LAN. As opposed to TCP, which is good for slower data, it automatically corrects errors, you don't need to worry about if it reaches the other end or what order it gets there in, because all that is sorted for you. Of course the headers are larger and almost prohibitive for an action game with a lot of stuff that needs updating. |
| ||
| True, but still both EverQuest and WoW used TCP/IP. The trick is correct interpolation of player positions :) |
| ||
| Ozak has no clue either. Perhaps Everquest uses TCP for login, or account maintenance, but clearly not for game play. Why would they consume extra bandwidth of TCP, and include extra delay for lost packets? Sony's EQ Tech site explains the use of udp in detail, and makes no mention of TCP/IP. http://eqlive.station.sony.com/support/tech_support/ts_network_support_security.jsp I think some anonymous poster said it best, "TCP is a reliable protocol. Although this sounds like I'm paying it a compliment, it can be a bad thing for games. Reliable means that the packets you send are received in the same order. If you send packets: X -> Y -> Z they are received as X -> Y -> Z This is great for chat/communication, but horrible for just about anything else. In UDP packets are received in the order that they arrive. Which is great for movement, or actions, because the last action is less important than the current action. You can mitigate the problems with out of order sequences on UDP very easily, simply by queuing the messages as they arrive, and then re-requesting those that didn't make it. Once your packets are ordered, then you can process them. Unfortunately there is no mitigation for the reliability of TCP. If a packet is dropped, then no new packets will be accepted until the missing packet arrives. This can cause a great amount of perceived lag. Have you ever played a game where you are moving your sprite, and then all of a sudden you stop moving, so you keep hitting the forward button. Then, all of the sudden your sprite bursts into a fast-forward sprint. This is because the movement packets were sent with TCP. I would strongly suggest that you use a network API that mitigates these problems for you. Most of them do. I see no feasible reason to use TCP, except to be lazy." As for World of Warcraft, maybe they do use TCP/IP for game play, maybe that's why it sucks. I know one of the reasons I stopped playing WOW was because large groups caused unplayable lag. Everquest, Camelot, and Asherons Call all appeared to do a much better job of managing packets. .02 |
| ||
| Actually the everquest emulator uses TCP/IP thus proving the game runs TCP/IP or the client would fail to run with it. (But that's beside the point, both protocols would work fine for the job) UDP is even worse as packets get lost, duplicated, and severely delayed. The ping time is huge on the internet due to slow routers, long travel time etc. And you can't even trust TCP/IP if you are not quick enough to read packets from the driver queue they are simply lost. So no matter what you use, you'd have to do some kinda dead reckoning. And your position is never used directly causing the sprite to stop moving. And for the record I worked many years as a programmer of online software (both servers and clients) and I do know how it works from a professional perspective. Please have your facts straight, before talking down to people. It appears you are the one with no clue :) |
| ||
| I removed my post, giving up smoking / nicoteene craving made it more agressive than productive... |
| ||
| i dont think this is right. "In UDP packets are received in the order that they arrive" u missing IF THEY DMM PACKED IN UDP ARRIVES ! Packet can also be corrupt in udp. so i stay away from it on internet its TCP/IP that count |
| ||
| the below is wrong too. TCP/IP "And you can't even trust TCP/IP if you are not quick enough to read packets from the driver queue they are simply lost." blitz3d has 8k buffer. never send more info than that at same time.. or else it will lag good :) Hint to speed upp tcp: iam not expert on UDP just TCP cause i use it well. Just create 2 ro 10 tcp streams and u get faster connection :) |
| ||
| so i stay away from it on internet its TCP/IP that count Stay away from it all you wish, but your claim that UDP is for lame network games is ridiculous. If you know what you're doing, UDP is much faster, even when you account for the extra packet you have to send to get reliable, ordered UDP. |
| ||
| UDP does include a checksum so you shouldn't get currupt packets (guess they are just lost instead)... well so far i have never seen one and I use UDP heavily. |
| ||
| True, but still both EverQuest and WoW used TCP/IP. The thing about these games and most other MMORPGs is that they are not realtime or action games. They do not need to synchronise a fast moving projectile on all connected machines and have it hit the destination at the same time in the same place. They are almost turn based - you click Attack and when the server recognises your command, it enters you in combat mode... when you make a hit, it isn't being calculated on your machine first and then sent to the server, it is the server doing the calculations and then sent to your computer. Or every computer that is in your party etc... And there is a very noticeable delay between when you press 'Attack' and when battle mode commences. However, you can be sure that when you press Attack, you will definately enter Attack mode, because the server will never lose your 'attack' request. The magic of TCP. Sometimes it will just take longer than others... The trick is correct interpolation of player positions :) In MMORPGs, what you see on your screen is no where near a correct representation of what other people see on their screens. The real trick is to make the actions of all *appear* to be fluent and realtime on your machine. That is the hard task for the client... would they consume extra bandwidth of TCP, and include extra delay for lost packets? For games like that it can make sense. To reuse my previous example, you don't want to have to issue an 'Attack' command more than once before you will be noticed... Perfectly impossible/highly improbable to do something like a FPS over the net with TCP though... |
| ||
| Ok guys, got one more question for ya. Will the command UDPMsgIP() only return the IP for a local (LAN) connection or will it return the sender's IP via internet as well? I'm asking the because I see that HostIP() only returns Local IPs. |
| ||
| It depends upon the method of connection. If you connect to a machine using a LAN then a local address will be returned. If you connect remotely then a WAN address will be returned. This applies to both commands. You can fake a WAN connection if your server PC is the gateway to the internet (ie: not using a router) by specifying the IP# of the WAN connection and then, using your LAN connect the second PC to the servers internet IP# and then HostIP() returns the WAN IP. If you connect to the LAN IP# such as 192.168.0.1 then HostIP() returns the LAN IP. You might also be able to sort through IP's with countHostIP's and specify the index but i've not personally ever bothered with that so don't know for sure. EQ (and therefore I guess EqEmu) uses UDP. I suppose the EqEmu docs do not clarify it because most end users do not know what UDP is. This post being a prime example of that, and as UDP is using IP# for target ident, /shrug: 1+1=2. |
| ||
| Hi S_Seth As an alternative to dynamic IP connection you can use http://apurientertainmentstudios.no-ip.info or other, to get it please visit http://www.no-ip.com |
   |