UDP: prevent flood of a port with several packets
Community Forums/General Help/UDP: prevent flood of a port with several packets
| ||
| Hello, I am still working on datas transfert with UDP and i have found that if there are several clients programs, it is better to use several ports and several streams for the incoming packets. This way i can check each frame on all "receiving streams" using different ports if a packet (sent by a client program) has been received. The issue that i am thinking about but i don't know if it is common in reality, is if the server program has attributed a port and a "receiving stream" to a client program, and for some reason the client program and the server program are not able to communicate anymore. After a specific time without communication (not receiving a packet), the server program will disconnect the client program and have an empty slot ready to be taken by another client program. Now let say that the previous client program has not received any packet from the server program and does not know that it is disconnected, it will keep sending packets on the same port and this can cause a "flood" of the port. As i understand it, if the server program checks if a packet has been received in the "receiving stream" using this port and the packet is not from the wanted client program, and a packet from the wanted client has been received at the exact same time, then one will be lost isn't it ? Or is there a stack of packets waiting to be read ? If so, how to access it ? Is it in the same stream ? If so, if i have already finished to read a packet in a "receiving stream", is it a good practice to check several time in the same mainloop to see if there are others packets sent by others IPAs in the same stream ? Will they stay in the stack if i read only one packet per mainloop ? Perhaps a simple solution is to add a time out on the client program too, but let's imagine a chaotic situation where there are many client programs sending several packets to the same port of a machine, how the server program is supposed to manage that ? Thanks, |
| ||
| It's been a long time since I delved into any of this but I'm fairly sure if a connection has been lost between client and server then attempting to send any data will fail because your stream will be invalid. |
| ||
| MCP>>What you say may be true with TCP (i have not tested yet), but from my understanding and tests, with UDP there is no connection between a client and a server, there are only packets traveling from one program to a stream to a port of a computer to another port of a computer to another stream to another program. Hence the possibility of a "flood" of a port if several programs keep sending packets to the same port of a machine even if they are not supposed to. Anyway i guess this is a rare issue so nobody thinks about it. A possible solution would be to attribute a new port and a new stream to each new client and delete the old streams. This may limit the problem even if it will not avoid hackers to send many packets to all ports. |
| ||
| ...with UDP there is no connection between a client and a server... I genuinely didn't know that about UDP. I've just read a quick article on the subject and I'm quite suprised. My limited knowledge extends as far as TCP only. Are you absolutely sure your program will not benefit from TCP? UDP does sound like it's more hassle than it's worth when you read into it. |
| ||
| Are you absolutely sure your program will not benefit from TCP? I am learning how to use UDP and TCP because depending on the program, if it requires fast updates, UDP is, as i have read, faster, while TCP is more reliable (no packets loss, and the packets are received in the right order), but UDP can be used to have the same reliability as TCP but probably with a faster datas transfer (depending on how i code my routines and depending on how the blitz3d commands are coded...) UDP does sound like it's more hassle than it's worth when you read into it. As always, it seems complicated when you haven't done it, but then it is fully understandable and easy enough to use. If anybody has more tips to avoid a flood of a port by unwanted programs, please don't hesitate to post. Thanks |
| ||
| The way I do UDP is quite simply the program has to validate themselves before the port is accepted from that program, if the program cant validate itself within an allotted time then the stream is closed. All packets are read into a buffer and the buffer is processed sequentially looking for a packet header and footer (for my system it was <EPB> ...<EPE>) if the program only finds one ie <EPB> with no <EPE> then its an invalid packet and is disregarded. also if there is data with no headers this too is disregarded. This cuts down on corrupt or incomplete packets which is the bane of UDP. As for clients connecting from other programs the validation system makes sure its your game client thats connecting and not something like telnet etc. |
| ||
| By validation I mean the program connects to the server then the server requests a code string from the client, if the client cannot provide the string after x requests from the server the connection is terminated and the server logs the attempt and IP address. If there is a constant attempt to connect and not validate from the client and they cannot validate then its down the the programmer to choose either ban the IP or continue kicking it every time it connects and fails. |
| ||
| The way I do UDP is quite simply the program has to validate themselves before the port is accepted from that program, if the program cant validate itself within an allotted time then the stream is closed. So do you close the stream and avoid to use the port associated to this stream and then you create another stream associated to another port ? If yes this is what i thought i will do. All packets are read into a buffer and the buffer is processed sequentially looking for a packet header and footer (for my system it was <EPB> ...<EPE>) if the program only finds one ie <EPB> with no <EPE> then its an invalid packet and is disregarded. also if there is data with no headers this too is disregarded. So this means there is a stack of packets in the same stream and i can read several times in the same stream each loop to check if there are others packets ? This cuts down on corrupt or incomplete packets which is the bane of UDP. What do you mean by "corrupt or incomplete packets" ? I thought that if a packet was received, it was full and not corrupted. See my explanations here : http://blitzbasic.com/Community/posts.php?topic=100246 post #5 (some infos may be partially false) By validation I mean the program connects to the server then the server requests a code string from the client, if the client cannot provide the string after x requests from the server the connection is terminated and the server logs the attempt and IP address. I see, it is a kind of password. Good idea. If there is a constant attempt to connect and not validate from the client and they cannot validate then its down the the programmer to choose either ban the IP or continue kicking it every time it connects and fails. What to you mlean by "ban the IP" ? Do you mean that the server program will ignore all packets coming from this IPA or that it is possible to ban this IPA by asking Windows or the firewall to do this ? Thanks for your answer EdzUp, this is interesting. |
| ||
| So do you close the stream and avoid to use the port associated to this stream and then you create another stream associated to another port ? If yes this is what i thought i will do. no just close the stream and socket associated with that client connection So this means there is a stack of packets in the same stream and i can read several times in the same stream each loop to check if there are others packets ? I normally read the available bytes from the stream What do you mean by "corrupt or incomplete packets" ? I thought that if a packet was received, it was full and not corrupted. See my explanations here : http://blitzbasic.com/Community/posts.php?topic=100246 post #5 (some infos may be partially false) By validation I mean the program connects to the server then the server requests a code string from the client, if the client cannot provide the string after x requests from the server the connection is terminated and the server logs the attempt and IP address. you are NOT guaranteed to get complete packets with UDP networking especially over the internet, you will also get sometimes noise from the connection this sometimes appears as extra bytes in the stream. What to you mlean by "ban the IP" ? Do you mean that the server program will ignore all packets coming from this IPA or that it is possible to ban this IPA by asking Windows or the firewall to do this ? i mean log the ip address and if it tries to open another connection close it immediately. My networking system is in the code archives if you wish to pull it apart its an old version as im updating it but it will give you some ideas |
| ||
| http://www.blitzbasic.com/Community/posts.php?topic=100290 On ipod and editing is a nightmare :/ |
| ||
| you are NOT guaranteed to get complete packets with UDP networking especially over the internet, you will also get sometimes noise from the connection this sometimes appears as extra bytes in the stream. Ok, noted. Thanks again for these tips. |
| ||
| If I were you I would use a combination of TCP and UDP, this gives you the best of both. Use TCP to send the non-speed dependant data e.g. setting up sessions, UDP ports, parameters, other players etc. Use UDP for the speed sensitive data, typically with an algorithm to deal with some of the issues of UDP packets (out of order, lost packets etc.). This way it is quite easy for your networking to maintain critical data and still perform well. Have fun. Darkheart |
   |