getting round ISP fascism. (connection limits)
hello, we''re not allowed to have more than 10 concurrent connections with my ISP. Is there any way around this?
I get the impression that the ISP will block further attempts to connect to my server. Is there any way around this?
perhaps for the server to be a peer instead - that is the system could work like this
client app sets up a server and then connects to the main server. (and disconnects)
the main server now knows where to look and makes a connection to.
so its still your classic star diagram for the network architecture... just that its like a ring of servers with the real server a collection of client processes.
make sense? senseless?
thanks, thats another idea i had pondered but didnt know if it would work. That could rather simply things.
i''m just guessing here, but maybe you can use UDP, which is connectionless. you can use one socket to catch messages from any number of clients.
if i am wrong, someone say so and i''ll shut up
if i am wrong, someone say so and i''ll shut up
--- krez ([email="krez_AT_optonline_DOT_net"]krez_AT_optonline_DOT_net[/email])
quote:
Original post by xaxa
you can always change your ISP...
Best idea of the lot
But yeah the UDP one is a good one too.
i have to change isp, they have just imposed a 1gig download per day limit
It sounds like your ISP is stupider than any i've seen before....
This limitation was probably made to keep high traffic FTP and HTTP servers from operating... But like it was said before, using UDP to make your own protocol sounds like a good idea.
With UDP there is no actual connection at the protocol layer (see OSI model :D), so that allows you to go around such limitations... Also, they can't really tell how many ports you have listening on UDP so, there is no problem.
This might sound a little complicated to do, but its not a dumb decision, because UDP also helps avoid lag, as many informations can afford not be insured to tranfer in modern games, such as chat messages... With TCP you get the problem that if some information gets lost in the transfert it might be retrieved several seconds later, leading to more lag... In some cases its just better to wait for the next update to correct the previous errors. UDP has less overhead than TCP also.
On the other hand, going peer to peer might sound like fun... It's actually a good options for file sharing networks like gnutella, but for games, you have to rely on a server... There are many reasons for this, one being the fact that many clients don't have much upload bandwidth (most ISPs cap your upload nowadays).
The second problem is that going peer to peer without a central server allows you to cheat in a more easy way... You can fake some information, block some other... Send falsified info... Resulting in the fact that you get more control than you should as a player. I remember someone telling me about an old tank fight game like that, it was peer to peer, so you could just use some proxy server to block some packets, and when it was time for your tank to die, you would block that event, so your tank would just refuse to die, or even catch ammo boxes that dont exist. With a central server, its always the server that has the final say, nobody can become invincible... That is, apart from the admins
Looking for a serious game project?
www.xgameproject.com
[edited by - Max_Payne on February 17, 2003 11:21:49 AM]
This limitation was probably made to keep high traffic FTP and HTTP servers from operating... But like it was said before, using UDP to make your own protocol sounds like a good idea.
With UDP there is no actual connection at the protocol layer (see OSI model :D), so that allows you to go around such limitations... Also, they can't really tell how many ports you have listening on UDP so, there is no problem.
This might sound a little complicated to do, but its not a dumb decision, because UDP also helps avoid lag, as many informations can afford not be insured to tranfer in modern games, such as chat messages... With TCP you get the problem that if some information gets lost in the transfert it might be retrieved several seconds later, leading to more lag... In some cases its just better to wait for the next update to correct the previous errors. UDP has less overhead than TCP also.
On the other hand, going peer to peer might sound like fun... It's actually a good options for file sharing networks like gnutella, but for games, you have to rely on a server... There are many reasons for this, one being the fact that many clients don't have much upload bandwidth (most ISPs cap your upload nowadays).
The second problem is that going peer to peer without a central server allows you to cheat in a more easy way... You can fake some information, block some other... Send falsified info... Resulting in the fact that you get more control than you should as a player. I remember someone telling me about an old tank fight game like that, it was peer to peer, so you could just use some proxy server to block some packets, and when it was time for your tank to die, you would block that event, so your tank would just refuse to die, or even catch ammo boxes that dont exist. With a central server, its always the server that has the final say, nobody can become invincible... That is, apart from the admins
Looking for a serious game project?
www.xgameproject.com
[edited by - Max_Payne on February 17, 2003 11:21:49 AM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
Recommended Tutorials
Advertisement