Network Code
Blitz3D Forums/Blitz3D Programming/Network Code
| ||
| I have a few questions about network coding: First, how is it possible to test server-client network code if you don't have access to more than one computer? Can you just run the server and client on the same machine, or will this not accurately reflect how the code would work when it's actually going over the internet. Second, I know everyone recommends UDP when large numbers of players are going to be playing at once, but then how is World of Warcraft able to run almost lag-free? |
| ||
| Can you just run the server and client on the same machine, or will this not accurately reflect how the code would work when it's actually going over the internet. I did a test a while back about this and you will be able to connect to the server if the server is on the same machine the client is, but other computers might not. Well that's what it was like with me until I figured out that I had an error in my code. Second, I know everyone recommends UDP when large numbers of players are going to be playing at once, but then how is World of Warcraft able to run almost lag-free? You mean all movement of characters in World of Warcraft is being sent using TCP? |
| ||
| Yes, as far as I know, everything in World of Warcraft is sent using TCP. I'm not sure I understand you're reply to my first question. Are you saying that the code worked until you tested it out on separate computers? Thanks |
| ||
| TCP in Blitz is no option because the call is blocking. This means until the data is really sent and received on the other side you app waits. WoW does not do that, it handles the networking in an own thread. And fully testing it on one machine is not possible. There are a few things that don't exist in that environment: 1. Packet Drop -> UDP are not always received so you must have some kind of mechanism to make sure that important ones are always received (Ack - Nack) 2. Latency does not exist. So you normally don't suffer the problems you do over net when it comes to interpolation and intrapolation of data (positions of players mainly, everything else is server emulated and does not need to be intrapolated but interpolated by the client) |
| ||
| even packet drop and latency can be simulated though. The trick is to create a seperate program that simulates the packet drop and latency. Packet drop is easy, have the middle program just drop a % of the items that are sent. Latency is a little harder, but for each message give it a time range that could be applied before it is delivered. |
| ||
| I'm not sure I understand you're reply to my first question. Are you saying that the code worked until you tested it out on separate computers? With TCP, yes. |
| ||
| Thanks for the replies everyone, and thanks for clarifying the WoW thing. One more thing, will testing the server-client code on two computers that are connected to the same network through the same router accurately simulate latency and packet drop or will I still have to design a middleman program as dynaman suggested? |
| ||
| you will need to have middleman program. The internet is worse than a single router in your local lan will be. But a good designed network layer actually would remove that tests as well. You just need to have 2 (1) feature: 1. Reliable UDP messages. Not that hard. 2. If you want to have them in the correct order, you would need to implement ordering on the receiver end. And if you are interested in an optimized solution you start looking for a solution that is simple and that offers that ... and over short or long you will struggle over the Blitz ENET userlib ;-) Then the only thing you have to do is think about Intrapolition and Interpolition where needed |
| ||
| TCP can indeed be used for a MMRPG. One rule 1 packet size.. alway 1 PACKET size. like packet size of 512 or 1024. Use readavail ;The command to use readbyte"S" Forbidden commands. readbyte readline readint readlong readshort i have ben coding MMRPG using blitz basic sens 2003 and it can handle over 150 users at once. Lag free ? Wow lags a lott internet delay of 2000 ms and it still works. In a counter strike game data is sent more frequent. In wow data is only sending the users destination. Look for "mangos project" it show you source code in C++ :D |
| ||
| [quote] Look for "mangos project" it show you source code in C++ :D [\quote] and [quote] i have ben coding MMRPG using blitz basic sens 2003 and it can handle over 150 users at once. [\quote] both very intersting points Wings, cheers, BP. |
| ||
| "Wow lags a lott internet delay of 2000 ms and it still works." 2000 ms? Did you mean 200 ms? That's what it was when I played. At worst it got up to 1500 ms on very rare occasions, but when it was that slow it was barely playable. Oh, also could you clarify which commands I should use if I use TCP? You're list is a little confusing. (Should I use readavail or readbyte or both?) I checked out your website Wings, it looks like a cool game so far. Just wondering though, how were you able to test if it would work with 150 players? |
| ||
| no i can play wow in 2000 ms so UDP or TCP dosent matter. I have 2000 ms then there is error in my isp network. (2 second lag :D) ordinary u have 40-240 ms to the wow server. the point is TCP is engought :D |
| ||
| Thanks for the help. Oh, by the way Wings I think there's something wrong with your website. Whenever I click on a different page it just reloads the home page. Just to let you know. |
| ||
| TCP is not fast enough for realtime in Blitz. Not because it is slow but because the whole game will stop while the transfer is ongoing. for a roundbased game thought its great :) |
| ||
| TCP is not fast enough for realtime in Blitz. Not because it is slow but because the whole game will stop while the transfer is ongoing. False: Sooooo many uses TCP and it works good :D But you have to think over the code before writing it. Like dont send a packet untill its ben recived :) ) To all who give tcp a shoot. use STATIC size of packets. try to think out how packet shold look like. Never use sigle write int commands.. write the whole data in one chunk. |
| ||
| I'm sorry but blitz does not offer that. A TCP message is sent until it is received. There is no possibility for you to control that. That is how blitz handles TCP! It makes no difference how genius your code is, blitz does not mind. TCP message not received -> halt until its done, point. If you don't want that: 1. Use UDP 2. Use an external library that offers TCP in a nonblocking way. |
| ||
| I'll probably just use UDP anyway but are there any external TCP libraries like what you mentioned that you can suggest? |
| ||
| Blitz TCP works fine. iam building eninge for over 1000 users online same time with it. I dont see any delays att all in my code. cause i handle it propper. But you must be able to controll it propper. 1) use readavail() 2) always use static size.. 3) whatever you planing to use.. Think ahead. draw everything down. Make a spread sheat how packet shall look like. Many fails with TCP cause its some kind of hard to understand. but in the long run those who use it wins time at the end. I whold never use UDP for a RPG. sens its so unsecure. |
| ||
| Are you sure it will work for that many players though? How did you test your code to make sure it could handle that amount of people? |
| ||
| Wings: How about testing it at least ONCE before claiming it works? I mean under real circumstances with 200ms lag from player to you back to player. The problem is and never was the reading. Nobody would be that stupid to read all the time if nothing is available (you would instant crash your app by the way, reading 0 stream) The problem is that Blitz will try to send a message until it either is received by the target system or the connection times out. At latest at that point, you will see how greatly useless your theory on blitz internal TCP support is. There are solutions to that thought by using an external library that does nothing else than "queues" up your messages and that gives your app the incomming messages on a query but otherwise works within its own process. That way you will have the superb features of TCP and have it realtime. But pure Blitz: No chance. Even with UDP, it wouldn't be powerfull enough for a 1000 player networking, just to mention that. Blitzs loop time is too high to handle several tousand messages per ms if you intend to react to them and generate new packages to be sent out. I would highly suggest thinking ahead as you claim you do, and use at least BlitzEnet if you are not willing to use one of the larger scale powerfull but complex library. |
| ||
| I have test TCP in blitz3d and it works with no problem. even from slow networks. thoe i only send 1 packet at a time. I dont se why any one whold want to send a bunch of packet at once yet :D vause if you dare to send every 10 ms the internet connection die soon in a RPG game. |
| ||
| What about if the server was in some other language, C++ or Python for example, would I be able to use TCP then if only the client was coded in Blitz? |
| ||
| I could be wrong, but I think Blitz only hogs the program with TCP if you set the message to "reliable"; otherwise it shouldnt "freeze" the program at all. BTW:I would love to see some MMO code for B3D... |
| ||
| I'm not quite sure who to believe here. I'm getting conflicting reports from everyone... Slotman, I can't figure out any way to set a message to "reliable". Is there a specific command for this? |
| ||
| I can only tell from my experience. 2003 i had just learned about blitz3d 2004 messing with TCPIp whooo why to it lagg.. fault trace and so on... 2004 Found the bugg. My server Halts cause the TCPIP buffer Lying in tcpip. Packets seam to arrive difirent times. and this cause TCPIP readavail lying about size of buffer. 2005 Found the workarond for that Nasty tpcip lag. Its simple medecine is to have Static size of packet, and have a sneaky sending.. i So in order to create a good running engine in blitz3d tcp. there is soem basic rulze. 1) Always have static size of tcp packet size. 2) Always user readavail() before readbytes() 3) Always user readbytes(),Sendbytes() Never ever putt more than 8k into the stream :D I dont say its easy to understand. I just says it works good if propper used. Also there is no GOOD tcpip engine at CodeAcrive.. thats saad :( |
| ||
| Found some horror code for a blitz3d Server, --------------------------------- Data1=ReadByte(file1) WriteLine(stream, Data1) ------------------------------------ the above lines is a good example how to make a server HALT :D First it reads from stream 1 byte (its ok if ther is a byte there) Second it dosent check if there are any bytes in that stream. if it is not it will halt execution untill there is data. but in worst case there is other data arives before tha first data and this makes server HALT at first step. So if you gona write a good tcpip engine folow my rulse :D |
| ||
| ---------------------------- Horror code ---------------- WriteLine(stream,"Player Cords") WriteLine(stream,xpos) WriteLine(stream,ypos) WriteLine(stream,MouseX()) WriteLine(stream,MouseY()) -------------------------------------------- |
| ||
| Here it a brief description how i use TCP. 1) Create a memmory bank on server. lile 512 bytes 2) Poke values into that memmory bank. 3) Send this memmory bank to clients. in one big packet. 4) wait for client to respond before sending next packet. that way server never lags. |
| ||
| Wings, youre missing the point... no matter how to design it, the problem is internally with the way blitz handles that sort of thing... TCP messages that dont arrive will be sent until either they receive a receipt or the send times out. This wait time will hang your application no matter what you do. Blitz does not have the ability to multi-thread. Having anymore than 8 or so people on a TCP only network game that is action based is going to push the limits in blitz. Thats just the way it is. If you are using an outside library or application that operates in its own thread then yes you can use tcp in a sly fashion and get it to work right. But they way you are doing it simply will not work. It may work on a gigabit lan sending small-medium sized packets but it will certainly fail with 10 dsl users spread out across a country. Trust us. Noting that even UDP is flawed in the fact that, A. Yes its fast, but you have no idea what packet is arriving in what order and if the entire packet was completed. You could send a few integers and not even receive the same number on the other end if the network hiccups. So in order to do packet checking and receipts/crc handling (in blitz anyways) its going to bog down almost as much at tcp. In the end, TCP is bad for a lot of real time stuff because each connection has a thread... its great for security and reliability, but lacks the speed that UDP gives you... UDP lacks the security and packet checking/verification that TCP has. Each has pros and a cons, and regardless if you are making any sort of non-turnbased game in blitz that will require more than 5-8 players, I would *highly* suggest using an external library to handle your network stuff. -Scott |
| ||
| I'm not sure if this is a stupid question, but is it possible to use winsock.dll in blitz if I could find or write a .decl file? And if so, would using winsock solve the blocking problem of using TCP in Blitz? |
| ||
| Forget what I just said. After your suggestions to use a network library I downloaded RottNet and have been attempting, unsuccessfully, to figure it out. Does anyone have any examples of a simple client-server program using Rottnet? Right now I am simply trying to send a players position between the server and all the clients but I don't even know where to start. |
| ||
| Ringwraith, Might I suggest learning how the process works first? If you are having problems with this, then there will be a boat load of problems to come. I know it sounds stupid, but trust me on this. Simply plot and draw out what to send to the server, and how the server will take it apart. A client/server chat room is a great place to start. No graphics or anything just a text prompt(not input as it hangs the app) for sending and receiving of messages. This is the whole basic principle behind it all. Then work on sending the chat messages more efficiently. Once you have a good messaging system, its easy to do it on a byte level and using UDP with some degree of error checking for "the important parts" you shouldnt have any trouble developing from there. There are many libraries out there. K-Net is a good one I think, however; lately I have been having some problems with it on a real server type environment. And honestly I must say, Blitz isnt bad for a client, but for a server its starting to become a pain for me haha. Best of luck! |
| ||
| Well, that's sort of what I'm trying to do here, just sort of mess around with the code and try to figure out what's really going on. Do you know of any good tutorials for networking in Blitz? That would be a real help, although given past experience it's far easier to find tutorials for languages like C++. P.S. Isn't K-net lib only for b-max? |
| ||
| Iam not missing any points ? tell me exactly how slow the send command is ? where is the slownews ? i am qureus. cause i fail to se any att all. even at 250 ms delays. ? |
| ||
| At a latency of 100ms it will take at least 200ms until your program will continue after sending the TCP data. And by "until continue" we really mean: Your app will be frozen, no further processing of anything. As mentioned, TCP operations (like file operations as well) in Blitz are blocking commands, which means that whenever they perform anything the whole remaining app must wait until they finished their work. Thats the main difference to Blitzs UDP implementation: You can send and receive and it will not wait until something has happened. It will just let the hardware handle it and read out the data / write the data to those ends. So you can even implement Blitz side security checks (for sending etc). RottNet is a simple, yet effective implementation example on that. I personally would use BlitzEnet, as it is the best "simple" network wrapper onto UDP with reliable and ordered packet send. You can use RakNet as well, there is a wrapper, but it is several times harder to understand it. If you want a little of both those worlds, the K-Netlib might be right thing for you. |
| ||
| At a latency of 100ms it will take at least 200ms until thanks testing your theory now. :D |
| ||
| test complete.. here is proff of that delay 200 ms cause 0 ms delay on server.. So no delays what so ever ? Where is the delays every one screams about ? and after they cream about it they try to sell a crappy UDP engine ? This test is based on 40 clients connects via 3g modem to server. Ie the modem broadband was driving full. still no sign of the lag you talk about.  Here is source code to test for you self. http://www.blitzbasic.com/codearcs/codearcs.php?code=2182 |
| ||
| ringwraith Question 1) Yes Question 2) yes, WOW is in fact only sending then needed. If you Go UDP or TCP or Whatever engine. same rule applyes. Wow dont send every hitt.. in fact some dimes then i have 5000 ms in lagg. my charter continues to strike and hitt oposite force.. and some time i win some time i lost. often a 5sek lag in wow = disconnected from server :D |
| ||
| by the way my network ISP now work OK again :D no more lagging. |
   |