Hmm, bot to bot communication is always a tricky one. There are several different concepts...
1) Interbot communication within the same
application.
2) Bot "communication" through the server.
Either by the use of profile entries, or
various other means (beep comes to mind :D).
3) TCP peer to peer communication.
I would assume you would be talking about the
3rd method or something similar to a "bot net".
I might recommend a peer-to-peer message passing
system, using a protocol much like bnet uses.
This would allow trusted (or if you allowed -
untrusted) clients to talk with each other. The
system would need a few standardized messages
to determine things such as
Suggested:
* FF?? - Bot "Owner"
* FF?? - Bots On Program
* FF?? - Other Bots on the BotNet
We would need to pass IP's and Port's.
* FF?? - Sending messages to other bot's on the
botnet through an intermediary.
* FF?? - Say "this" with this bot?
* FF?? - Are you free to enqueue a msg?
Subject to Bot Implementation:
* FF?? - User Info Request
We would want a standardized port (probably around
6112, but not 6112) for this as well, but there
would be no need to require the use of that port
specifically.
In a sense this would be similar to a
gnutella-like network, where each peer connects to
(n) other peers and can also request information
through intermediate links. This differences in
you would generally only allow "trusted" links
on your "bot network". IE: clans who would like to
war each other would not want the other clan to
have access to their bot network. :)
So, what am I missing...? Some sort of a basic
password authentication sequence? Might be nice,
we could use SHA-1 as every (binary) bot would
have this already.
This is by no means meant as a RFC quite yet. >;-)
Just throwing out ideas.
-eurijk!
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We're on the same page as far as B2B communication goes; however, I'm wondering whether P2P would be the way to do this. A central "hub" bot may or may not be a better solution. Some important things like rejoining a channel when it's empty and sharing a userfile require both speed and some definition of precedence. For instance, if you have 8 bots on a channel, there are no ops, and they're the only 8 users there, who's to say which bot rejoins? When sharing userfiles, which bot has the master userfile? What happens if that bot arbitrarily connects to another bot that thinks it has the master userfile? Do you share userfiles? It really is a pain not to. I'm still open to suggestions, but a true P2P network seems rather convoluted. -Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Hmm.. more thoughts. I'm not too familiar with SHA-1, but I'm under the impression that it's an irreversible hashing method. It would be a good idea to encrypt the passwords across network connections, but it would be even better if they could be encrypted when stored locally. This presents the problem of decrypting them. For this, something like blowfish seems suitable. In fact, the entire userfile could be encrypted using blowfish with no problem, but would we want to force people to have to edit the userfile through the bot only? Parsing would be easier, and security would be better.. thoughts.. jumbled.. -Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've written bot to bot communication code using C before, and it wasn't nearly as hard as it is in C++. The data structuring will pay off, surely.
Can I use the Net class to deal with the net part of B2B communication, or is that just for the server messaging? I'm staring blankly at the code, wondering where I could put hooks for the botnet handlers, so I obviously don't understand the code well enough yet. I can, however, design the protocol and member functions now. -Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Yeah, the data structres make it look intimidating, but it really shouldn't be too bad.
There are a couple of different means of implementation. A simple one would be to make a B2B class that connected to a centralized server. This could be done by something like (see below) where the bot would simple use the B2B class instead of the BOT class. The disadvantage to using this method is every bot would need a fd to the centralized server, rather then just one fd for all the bots.
Perhaps a better implementation would be to have a B2B message passing system. Implementation of that may take some design planning, both on the side of the server, and the implementation. The advantage to this is only a single fd would be open per prolix processes, and bots could use the system to communicate locally w/o needing to go through the server first. This would probably be a better implementation, but would need some serious protocol work for conformity first I would think. <shrugs>
Your thoughts ?
-eurijk!
// quick possible example of a bot to server
// B2B scheme.
// Pluses: It's simple and quick, not too confusing.
// Minuses: Every bot would need to connect to the B2B server. (bots would need to inherit the B2B class and not the BOT class)
class B2B : protected Bot {
public:
Net *b2b;
B2B::B2B( void) {
try {
// This probably needs to be added to the netthread
// see config.cpp.
b2b = new Net(...);
}
catch (...) {
*log << "Error: Unable to allocate a new net for b2b..." << endl;
b2b = NULL;
}
}
virtual ~B2B( void) {
if (b2b)
delete b2b;
}
virtual void pkt_connected( void) {
// Figuring this out might take a few compares,
// perhaps I should modify pkt_connected to pass
// the "net" that is concerned. hmm
if (net connected and not us) {
bot::connected();
return;
}
// Otherwise, send hello.
// FF 01 ?? 00 'H' 'e' 'l' 'l' 'o' '\0'
*brb << "Hello";
brb->sendpkt( 0x01ff);
}
virtual void handle( void) {
// Run this first to keep the bot latency down.
Bot::handle();
if (!brb->isConnected() && !brb->isConnecting()) {
// do the connect
}
if (!brb->isConnected()) {
// ...
return;
}
int pkt_len, pkt_type; char *pkt_buf;
while (pkt_buf = net->getpkt( pkt_len, pkt_type)) {
switch( pkt_type) {
case 0x01ff: // they said hello back :)
default:
// blah
}
}
delete pkt_buf;
}
};
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I'm working on the implementation of a B2B messaging protocol. I chose to adopt the latter method of one fd to the server. Each bot would be its own entity, but there would be one bot defined as BOT_NET, and the rest would be BOT_IPC. The BOT_IPC bots send messages to the BOT_NET bot, which relays them to the connected bots. The differences would be entirely encapsulated, of course. It is a daunting task, and I'm looking into some inherited classes of my own. What I'm concerned with right now is the messaging protocol and encapsulating the IPC and the NET messaging. I'll post my results when I finish them and clean them up a bit. Might be a while.. finals next week (AHHHHH!) -Peter
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
New features can be modularized, so I figured I'd throw some ideas around for modules I'd like and will probably write.
-Bot to bot communication
-User access scheme
-Encrypted userfiles + checksums
-Random quotes
-System statistics
-Detachable/reattachable display
-File transfer between trusted Prolix bots
Feel free to post about any new features, as others may have insights as to how to implement them if you're unable to for some reason.
Hmm, bot to bot communication is always a tricky one. There are several different concepts...
1) Interbot communication within the same
application.
2) Bot "communication" through the server.
Either by the use of profile entries, or
various other means (beep comes to mind :D).
3) TCP peer to peer communication.
I would assume you would be talking about the
3rd method or something similar to a "bot net".
I might recommend a peer-to-peer message passing
system, using a protocol much like bnet uses.
This would allow trusted (or if you allowed -
untrusted) clients to talk with each other. The
system would need a few standardized messages
to determine things such as
Manditory:
* FF00 - Keepalive
* FF01 - BotType (string) ?
* FF02 - BotVersion (string) ?
Suggested:
* FF?? - Bot "Owner"
* FF?? - Bots On Program
* FF?? - Other Bots on the BotNet
We would need to pass IP's and Port's.
* FF?? - Sending messages to other bot's on the
botnet through an intermediary.
* FF?? - Say "this" with this bot?
* FF?? - Are you free to enqueue a msg?
Subject to Bot Implementation:
* FF?? - User Info Request
We would want a standardized port (probably around
6112, but not 6112) for this as well, but there
would be no need to require the use of that port
specifically.
In a sense this would be similar to a
gnutella-like network, where each peer connects to
(n) other peers and can also request information
through intermediate links. This differences in
you would generally only allow "trusted" links
on your "bot network". IE: clans who would like to
war each other would not want the other clan to
have access to their bot network. :)
So, what am I missing...? Some sort of a basic
password authentication sequence? Might be nice,
we could use SHA-1 as every (binary) bot would
have this already.
This is by no means meant as a RFC quite yet. >;-)
Just throwing out ideas.
-eurijk!
We're on the same page as far as B2B communication goes; however, I'm wondering whether P2P would be the way to do this. A central "hub" bot may or may not be a better solution. Some important things like rejoining a channel when it's empty and sharing a userfile require both speed and some definition of precedence. For instance, if you have 8 bots on a channel, there are no ops, and they're the only 8 users there, who's to say which bot rejoins? When sharing userfiles, which bot has the master userfile? What happens if that bot arbitrarily connects to another bot that thinks it has the master userfile? Do you share userfiles? It really is a pain not to. I'm still open to suggestions, but a true P2P network seems rather convoluted. -Peter
Hmm.. more thoughts. I'm not too familiar with SHA-1, but I'm under the impression that it's an irreversible hashing method. It would be a good idea to encrypt the passwords across network connections, but it would be even better if they could be encrypted when stored locally. This presents the problem of decrypting them. For this, something like blowfish seems suitable. In fact, the entire userfile could be encrypted using blowfish with no problem, but would we want to force people to have to edit the userfile through the bot only? Parsing would be easier, and security would be better.. thoughts.. jumbled.. -Peter
I've written bot to bot communication code using C before, and it wasn't nearly as hard as it is in C++. The data structuring will pay off, surely.
Can I use the Net class to deal with the net part of B2B communication, or is that just for the server messaging? I'm staring blankly at the code, wondering where I could put hooks for the botnet handlers, so I obviously don't understand the code well enough yet. I can, however, design the protocol and member functions now. -Peter
Yeah, the data structres make it look intimidating, but it really shouldn't be too bad.
There are a couple of different means of implementation. A simple one would be to make a B2B class that connected to a centralized server. This could be done by something like (see below) where the bot would simple use the B2B class instead of the BOT class. The disadvantage to using this method is every bot would need a fd to the centralized server, rather then just one fd for all the bots.
Perhaps a better implementation would be to have a B2B message passing system. Implementation of that may take some design planning, both on the side of the server, and the implementation. The advantage to this is only a single fd would be open per prolix processes, and bots could use the system to communicate locally w/o needing to go through the server first. This would probably be a better implementation, but would need some serious protocol work for conformity first I would think. <shrugs>
Your thoughts ?
-eurijk!
// quick possible example of a bot to server
// B2B scheme.
// Pluses: It's simple and quick, not too confusing.
// Minuses: Every bot would need to connect to the B2B server. (bots would need to inherit the B2B class and not the BOT class)
class B2B : protected Bot {
public:
Net *b2b;
B2B::B2B( void) {
try {
// This probably needs to be added to the netthread
// see config.cpp.
b2b = new Net(...);
}
catch (...) {
*log << "Error: Unable to allocate a new net for b2b..." << endl;
b2b = NULL;
}
}
virtual ~B2B( void) {
if (b2b)
delete b2b;
}
virtual void pkt_connected( void) {
// Figuring this out might take a few compares,
// perhaps I should modify pkt_connected to pass
// the "net" that is concerned. hmm
if (net connected and not us) {
bot::connected();
return;
}
// Otherwise, send hello.
// FF 01 ?? 00 'H' 'e' 'l' 'l' 'o' '\0'
*brb << "Hello";
brb->sendpkt( 0x01ff);
}
virtual void handle( void) {
// Run this first to keep the bot latency down.
Bot::handle();
if (!brb->isConnected() && !brb->isConnecting()) {
// do the connect
}
if (!brb->isConnected()) {
// ...
return;
}
int pkt_len, pkt_type; char *pkt_buf;
while (pkt_buf = net->getpkt( pkt_len, pkt_type)) {
switch( pkt_type) {
case 0x01ff: // they said hello back :)
default:
// blah
}
}
delete pkt_buf;
}
};
I'm working on the implementation of a B2B messaging protocol. I chose to adopt the latter method of one fd to the server. Each bot would be its own entity, but there would be one bot defined as BOT_NET, and the rest would be BOT_IPC. The BOT_IPC bots send messages to the BOT_NET bot, which relays them to the connected bots. The differences would be entirely encapsulated, of course. It is a daunting task, and I'm looking into some inherited classes of my own. What I'm concerned with right now is the messaging protocol and encapsulating the IPC and the NET messaging. I'll post my results when I finish them and clean them up a bit. Might be a while.. finals next week (AHHHHH!) -Peter