The "perceived chance of success" isn't even a consideration in modern bots. The bots are being run from compromised hosts, primarily windoze machines on broadband connections, so the bot operators don't much give a fiddler's frock about efficiency.
Hmmm... just for the sake of argument, let's do a high-level stream of consciousness build of your system. You've mentioned NetServer::Generic which is a fine choice if you're not handling a ton of traffic and don't need a select based server, but it attaches meaning to line terminator characters. If you can't jam all of your data into one long string, you'll need something else. Just for giggles, though, we'll implement DJB's silly Netstrings idea via Text::Netstring to solve that problem. Now we have the guts of the beastie, and we have to give it a thick hide. Let's wrap our streams in SSL to keep the nosy neighbors out of our business, and plug in some sort of authentication that's invulnerable to replay. Pick one of the trendy ones just for geek points. So far, so good. Okay, now we get to address the original points, probing and DoSing. Let's do some rolling state maintenance, SQLite works well for this. But we don't want our server to have to deal with the load because all we really need to know is that ww.xx.yy.zz shouldn't be talking to us on port nn (deja vu!) so we'll enlist the help of IPTables::IPv4. There, problems all solved. It's a lot of work, but we've done it... never mind that our server isn't going to stand up to the load if we get really popular, for now.
Or you could save a lot of time and make the server side of your wonder widget a web service running Apache on a non-standard and unprivileged port, get SSL and authentication with very little effort, add in Zdziarski's mod_evasive Apache module to avoid much DoS nastiness, take advantage of scads of CPAN modules that are already written for extending Apache and maybe even manipulating the server's iptables (assuming Linux), and focus most of your energy on the client side. Sounds like a fairly simple approach with few unnecessarily reinvented wheels and leveraging some time tested code, to me.
Whaddaythink? Spend lots of time to get something that cannot handle big loads, or spend much less time to get something that can handle big loads and much of which will continue to get better over time without any help at all from you?
In reply to Re^5: How to implement a fourth protocol
by gloryhack
in thread How to implement a fourth protocol
by Moron
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |