Repost. List your Ideas HERE!

[tA-Kane]

i'd think a full fledged bot is more valuable then botnet

Agreed.

[Banana fanna fo fanna]

Anyone interested in created a REAL p2p botnet using UDP?

[Camel]

Anyone interested in created a REAL p2p botnet using UDP?

yes. preferably on a reliable connection.

[tA-Kane]

Anyone interested in created a REAL p2p botnet using UDP?

You don't like BotNet? Actually, there's several key points that I don't like about what Kp claims to be "improving" the BotNet server and documentation. But all in all, the Valhalla Legends botnet is very nice (albeit rather sucky docs) for what it was designed for: the communication and coordination between bots, especially during (the now rare) Battle.net server splits. Oh, and by the way, UDP is eww++.

I beleive there's already an IRC standard for a bot network, but I'm not sure... I'd have to check into that.

[Kp]

Actually, there's several key points that I don't like about what Kp claims to be "improving" the BotNet server and documentation.

All I've heard is complaint that the server won't let you use as long a battle.net name as you like; the documents never specified that you could use arbitrary length strings.  If you'd like to enumerate the failings...?

[pianka]

...Well what I meant is not using the already implemented IB, but a completely new one...? Like we all sit down for a week and setup a whole new protocal, add it to our bots and hopefully create something that will be used for a few years. But I doubt anyone would be interested, although if you are, e-mail me. I think me e-mail link is on the left, but if it's not, [email protected] is my e-mail. Or you could just reply to this thread, either way, it works. The new protocal, if we made one, would be a very interesting project, I'm kind of excited if you guys think it's a good idea, but if not, it's all good.

[tA-Kane]

By the way, I've put up the BotNet spec on my server at, since vl.com is unreachable:
http://kbg3.ath.cx/misc/BotNetProtocol.txt
I don't have your revision 0x04 docs backed up and as such, can't put them up on my server.

All I've heard is complaint that the server won't let you use as long a battle.net name as you like; the documents never specified that you could use arbitrary length strings.

Nor did they say the maximum length of the string (except that common sense states that the string length cannot exceed the maximum length of the packet, minus the length of the other datas of the packet).

If you'd like to enumerate the failings...?

1) C->S 0x0B: Protocol spec does not state you can not use action values other than 0 or 1 (emote vs non-emote). Though it works on old clients, you've now broken that for the new-server-aware clients. Additionally, it's a rather waste to have 3 possible values for the command, and 2 possible values for the action, and both parameters using DWORDs to communicate those values. Just combining both parameters into a single byte would be sufficient.

2) C->S 0x02: Does not provide a field for the gateway name, so if you were to add the gateway name by appending "@Gateway" to the unique battle.net name field, it gets cut off. Additionally, the unique Battle.net name field isn't unique if multiple bots are on the same account on different gateways (Eg, MacBinaryBot@USWest, MacBinaryBot@USEast, MacBinaryBot@Azeroth, etc).

3) No documented standard for how to display the bot as "offline", yet you get mad when I do it differently than the way other bots commonly do it.

4) C->S 0x02: The bot's cycle status has very little documentation. You tell me it's defunct (I've forgotten the term you used, but it's essentially old and useless), yet it still exists in the 0x04 revision.

5) You provide a user database, but no standard for which to store the user entries (eg, what values do what). This is more of a general complaint than a botnet server specific complaint, but if the server's supposed to support multiple bot types, then there should be a standard for the database entries.

6) The protocol supports server version and protocol version information. What's the difference between the two? If it's the protocol that's getting added to, why is it the server version gets changed?!

7) The 0x04 protocol supports protocol violation messages, but only to a limited degree: Packet data, and parsed length (and a useless packet data length; useless in that isn't it obvious that the packet data is the length of the protocol violation packet minus the length of the other parameter?). You say that it takes common knowledge to know that the error is at whereever the server stopped parsing the packet data. Yes, that's simple enough to understand. But what if the data looks good to the user? Perhaps you should also include an error message (beit a string or an enumerated integer, or both), stating the type of error which occured, such as these basic errors:

Code Select Expand

Parameter expected (aka packet too short)
Invalid parameter value (eg, privmsg action not being 0 or 1)
String parameter too long
String parameter malformed (such as a space in the account name, or no password provided when changing databases)
Access violation (client tried to do something restricted to verified administrators (logged in and account has access))
Bad connection sequence (eg, client requested bot list before providing its own bot stats, or before sending packet 0x01)
Server Error (internal server error required client to disconnect)
Other (eg, "See Attached String")
I'm sure there's more for me to complain about, but that's all I can think of right now... most of it is poor documentation.

Edit: Hehe, took me a long time to write this post; I started writing it before pianka replied  

[Kp]

1) C->S 0x0B: Protocol spec does not state you can not use action values other than 0 or 1 (emote vs non-emote). Though it works on old clients, you've now broken that for the new-server-aware clients. Additionally, it's a rather waste to have 3 possible values for the command, and 2 possible values for the action, and both parameters using DWORDs to communicate those values. Just combining both parameters into a single byte would be sufficient.

The protocol also doesn't state that you *are* permitted to use values other than 0 and 1.  Relying on things that happen to work at the moment is generally a bad practice, IMO.  I agree about the waste, but this can't be fixed without either introducing a new message or making message parsing even more complex for both sides.

2) C->S 0x02: Does not provide a field for the gateway name, so if you were to add the gateway name by appending "@Gateway" to the unique battle.net name field, it gets cut off. Additionally, the unique Battle.net name field isn't unique if multiple bots are on the same account on different gateways (Eg, MacBinaryBot@USWest, MacBinaryBot@USEast, MacBinaryBot@Azeroth, etc).

Botnet predates the Warcraft III name mangling, which I still maintain to be a bad idea.  Truncation of overlong strings is rather generous.  The server really ought to have disconnected clients which supplied excessive input.  This has been corrected.  Differentiating gateways (west v. east) is a property of the server IP field, not the name field.

3) No documented standard for how to display the bot as "offline", yet you get mad when I do it differently than the way other bots commonly do it.

Using "Not logged on" in angle brackets has become a de facto standard, as can be seen by observing existing clients in use.  If you choose to deviate, that's unfortunate, as other bots will not necessarily recognize you properly.

4) C->S 0x02: The bot's cycle status has very little documentation. You tell me it's defunct (I've forgotten the term you used, but it's essentially old and useless), yet it still exists in the 0x04 revision.

Skywing asked that the server retain support for it.  It is not being updated, but will remain supported in case someone can find a use for it.  Its original purpose was regenerating operator status in private channels by cycling out all bots, if only bots under control of a single entity remained in the channel.

5) You provide a user database, but no standard for which to store the user entries (eg, what values do what). This is more of a general complaint than a botnet server specific complaint, but if the server's supposed to support multiple bot types, then there should be a standard for the database entries.

The database takes a name field and a value field, where the value contains any of the letters A-Z.  The client is free to interpret the data however it pleases.  Aside from Zerobot, I've not been made aware of any bots seeking to store a database on the server.  If there are any, and they require other database support, I encourage the authors to contact me at my vL e-mail address to discuss possible support.

6) The protocol supports server version and protocol version information. What's the difference between the two? If it's the protocol that's getting added to, why is it the server version gets changed?!

The server version is a concept Skywing introduced, to let clients know what features are present.  Protocol version is something I introduced, with the intent of being able to determine what particular fields a message would have.  Server version will likely increase whenever a new feature is added; protocol revision probably will not change much.

7) The 0x04 protocol supports protocol violation messages, but only to a limited degree: Packet data, and parsed length (and a useless packet data length; useless in that isn't it obvious that the packet data is the length of the protocol violation packet minus the length of the other parameter?). You say that it takes common knowledge to know that the error is at whereever the server stopped parsing the packet data. Yes, that's simple enough to understand. But what if the data looks good to the user? Perhaps you should also include an error message (beit a string or an enumerated integer, or both), stating the type of error which occured, such as these basic errors:

Code Select Expand

Parameter expected (aka packet too short)
Invalid parameter value (eg, privmsg action not being 0 or 1)
String parameter too long
String parameter malformed (such as a space in the account name, or no password provided when changing databases)
Access violation (client tried to do something restricted to verified administrators (logged in and account has access))
Bad connection sequence (eg, client requested bot list before providing its own bot stats, or before sending packet 0x01)
Server Error (internal server error required client to disconnect)
Other (eg, "See Attached String")
I'm sure there's more for me to complain about, but that's all I can think of right now... most of it is poor documentation.

The present implementation of the parser simply returns true if the packet was acceptable, or false if the parser bailed out due to an error.  No facility is provided for it to indicate to the caller about the nature of the error.  I'll look at adding an enumerated type to be returned, but don't count on it.

[Banana fanna fo fanna]

I think the botnet sucks because it's centralized and not open.

[tA-Kane]

The protocol also doesn't state that you *are* permitted to use values other than 0 and 1.  Relying on things that happen to work at the moment is generally a bad practice, IMO.  I agree about the waste, but this can't be fixed without either introducing a new message or making message parsing even more complex for both sides.

It would have been better for the protocol spec to specify what happens to a request with bad values.

It might make message parsing more complex for you, but it's a simple change of 3 lines for me...

Code Select Expand

Old code:
 Command = StringToInteger(MidB(Buffer,1,4))
 Action = StringToInteger(MidB(Buffer,5,4))
 Buffer = MidB(Buffer,9)
Possible new code:
 Command = StringToInteger(MidB(Buffer,1,1))
 Action = StringToInteger(MidB(Buffer,2,1))
 Buffer = MidB(Buffer,3)
Other possible new code:
 Temp = AscB(MidB(Buffer,1,1))
 Command = BitshiftRight(BitwiseAnd(Temp,&hF0),4)
 Action = BitwiseAnd(Temp,&h0F)
 Buffer = MidB(Buffer,2)I don't understand how it would be so hard to write similarly (in VB or RB), I would probably need to at least understand a whole lot more about how you've implemented some of the things.

Botnet predates the Warcraft III name mangling, which I still maintain to be a bad idea.  Truncation of overlong strings is rather generous.  The server really ought to have disconnected clients which supplied excessive input.  This has been corrected.  Differentiating gateways (west v. east) is a property of the server IP field, not the name field.

I agree the name mangling is a bad idea. Yes, truncation of overlong strings is rather generous, considering that the protocol doesn't specify the maxmimum length of the string in the first place...
Oh, and by the way, the server IP field shouldn't be relied of for the gateway... suppose the bot is on a 3rd party gateway (such as BnetD or WarrNet, as some examples (not saying I support either of those))? As such, it wouldn't be in the server list of other bots, and so the gateway "lookup" could fail. And even if you put that aside, not all clients have all of the server IPs for each gateway and nor do all clients have domain lookup features (eg, if its told to connect to a domain instead of an IP, the provider does the lookup instead of the client).

Using "Not logged on" in angle brackets has become a de facto standard, as can be seen by observing existing clients in use.  If you choose to deviate, that's unfortunate, as other bots will not necessarily recognize you properly.

As you've stated elsewhere, if you were to join that exact channel, bots could then mark you as offline, even if you weren't.

Skywing asked that the server retain support for it.  It is not being updated, but will remain supported in case someone can find a use for it.  Its original purpose was regenerating operator status in private channels by cycling out all bots, if only bots under control of a single entity remained in the channel.

I don't see it as being very useful, in that the cycle status of client A does not get received by client B, and vice versa. Instead, all I see is the ability to send a request to cycle a channel, the ability to receive a request, and the ability to send the bot's cycle status. Since there's no acknowledgement received by the requester (AFAIK), nor by other bots (AFAIK), it seems fairly useless.

But, if this was received by other clients, then parameter would be where I would put a "Connection Status" parameter, after making it only a byte instead of 4, and would then remove the packet 0x05 (both C->S and S->C). Then, it could be reused in a later protocol version for some other feature (being that old ("legacy") clients won't support the new feature and new clients wont support the old feature...). Here's some example connection status values:

Code Select Expand

0x00: Not connected; Server is invalid (useful for services, such as BNLS or Webbot, perhaps with this value, the client would not be required to send the server parameter (though, it would require the server parameter to be moved to after this parameter))
0x01: Connecting
0x02: Connected; available
0x03: Reconnecting (I beleive WarCraft 3 supports some sort of reconnect feature, does it not? As such, is it not possible for a bot to reconnect?)

Additional (unneeded) values:
0x04: Disconnected; Server is old server

0x05: Proxy down (the bot could not connect to a proxy, which it uses to connect to Battle.net; suppose this could be either of the disconnected values though)

0x06: Bad Version (perhaps the bot does not support auto-updating its hash files, and the Battle.net server doesn't like the version (eg, version too old, unrecognized version); could be useful to see when a new product version has been released, and hashfiles need to be manually updated for services)

0x07: Bad Key (perhaps Battle.net has rejected a CD key and the bot does not have (or support?) autmoatically changing keys, or it out of new keys)

0x08: Server Down/Unreachable (perhaps the bot does not support automatically changing servers or all of the servers which is has are down or unreachable?)

etc etc, I could go one with other useless values...

The database takes a name field and a value field, where the value contains any of the letters A-Z.  The client is free to interpret the data however it pleases.  Aside from Zerobot, I've not been made aware of any bots seeking to store a database on the server.  If there are any, and they require other database support, I encourage the authors to contact me at my vL e-mail address to discuss possible support.

I wish to have support for storing a database on the server, probably in a different way than that of ZeroBot. I will contact you at your email address, then, since that's where you've requested this particular discussion to take place.

Though, I was under the impression that there were other bots that had supported such a feature.

The server version is a concept Skywing introduced, to let clients know what features are present.  Protocol version is something I introduced, with the intent of being able to determine what particular fields a message would have.  Server version will likely increase whenever a new feature is added; protocol revision probably will not change much.

IMO, the server version should change when it's being modified to support a new protocol version, changed when bugs are fixed, and etc. Additionally, IMO, it's the protocol version that should have changed when new features are added to it (such as the account management features in "server version" 0x02, and the "client supports X server version" and "client and server will communicate in 'server version' X" in "server version" 0x04).

I'm not saying that either of your intentions are invalid... it's just that they seem to be ambigous, with only one of them being updated.

The present implementation of the parser simply returns true if the packet was acceptable, or false if the parser bailed out due to an error.  No facility is provided for it to indicate to the caller about the nature of the error.  I'll look at adding an enumerated type to be returned, but don't count on it.

Now that you mention it, I remember you telling me as such. Yet, I still beleive there should be an error code, instead of just "an error occured". Perhaps you could create a variable (since I don't know how the BotNet server is structured, I'll just say in or with the packet's context, or perhaps in the data received function and pass a pointer to it in the packet's parser), which gets set to 0 at the default return, or to an error code at any other return. Then, if the parser returns true, you pass that variable along to the protocol violation handler, else, you ignore the value. If you *do* do it that way, then be sure to set init the value to either 0 or "internal server error", so that if you forget to set it in the parser, you won't send along an invalid error code value.

[Kp]

It would have been better for the protocol spec to specify what happens to a request with bad values.

Probably so.  However, using nonstandard values already causes you problems in communication.  Some clients (in particular mine) refuse to accept messages not in strict compliance with the specification.

It might make message parsing more complex for you, but it's a simple change of 3 lines for me...

Code Select Expand

Old code:
 Command = StringToInteger(MidB(Buffer,1,4))
 Action = StringToInteger(MidB(Buffer,5,4))
 Buffer = MidB(Buffer,9)
Possible new code:
 Command = StringToInteger(MidB(Buffer,1,1))
 Action = StringToInteger(MidB(Buffer,2,1))
 Buffer = MidB(Buffer,3)
Other possible new code:
 Temp = AscB(MidB(Buffer,1,1))
 Command = BitshiftRight(BitwiseAnd(Temp,&hF0),4)
 Action = BitwiseAnd(Temp,&h0F)
 Buffer = MidB(Buffer,2)I don't understand how it would be so hard to write similarly (in VB or RB), I would probably need to at least understand a whole lot more about how you've implemented some of the things.

The parsing change is simple -- if you don't mind losing backward compatibility.  The server is supposed to retain compatibility with clients using the current botnet, which will become "legacy" clients when we switch over.  For a client to remain compatible with a legacy server, it will need to consider the protocol revision each time it tries to parse a message.  Not hard, but it is more trouble.

I agree the name mangling is a bad idea. Yes, truncation of overlong strings is rather generous, considering that the protocol doesn't specify the maxmimum length of the string in the first place...
Oh, and by the way, the server IP field shouldn't be relied of for the gateway... suppose the bot is on a 3rd party gateway (such as BnetD or WarrNet, as some examples (not saying I support either of those))? As such, it wouldn't be in the server list of other bots, and so the gateway "lookup" could fail. And even if you put that aside, not all clients have all of the server IPs for each gateway and nor do all clients have domain lookup features (eg, if its told to connect to a domain instead of an IP, the provider does the lookup instead of the client).

Identifying someone's gateway is primarily desirable for determining whether they will be able to affect your bncs environment.  If they aren't on the same gate as you, they can't -- doesn't matter which gate they are on.  I've never seen a client that couldn't figure out what IP it was connected to, so anyone supplying a bogus IP must be either a bad programmer, intentionally deceptive, or using a really sucky language.

If you have some other use for gateway name, please say so.

As you've stated elsewhere, if you were to join that exact channel, bots could then mark you as offline, even if you weren't.

Unfortunate, but unavoidable.  Suggest an alternate value for that field that can't be accidentally spoofed by a user roving unusual channels?

I don't see it as being very useful, in that the cycle status of client A does not get received by client B, and vice versa. Instead, all I see is the ability to send a request to cycle a channel, the ability to receive a request, and the ability to send the bot's cycle status. Since there's no acknowledgement received by the requester (AFAIK), nor by other bots (AFAIK), it seems fairly useless.

Zerobot has a fair amount of clientside support involved in this.  If I read the code right, the logic is essentially that if the channel is comprised only of friendly bots, Zerobot asks everyone else to bail out.  When the channel is comprised of only itself, it rejoins to reacquire the gavel.

But, if this was received by other clients, then parameter would be where I would put a "Connection Status" parameter, after making it only a byte instead of 4, and would then remove the packet 0x05 (both C->S and S->C). Then, it could be reused in a later protocol version for some other feature (being that old ("legacy") clients won't support the new feature and new clients wont support the old feature...). Here's some example connection status values:

Code Select Expand

0x00: Not connected; Server is invalid (useful for services, such as BNLS or Webbot, perhaps with this value, the client would not be required to send the server parameter (though, it would require the server parameter to be moved to after this parameter))
0x01: Connecting
0x02: Connected; available
0x03: Reconnecting (I beleive WarCraft 3 supports some sort of reconnect feature, does it not? As such, is it not possible for a bot to reconnect?)

Additional (unneeded) values:
0x04: Disconnected; Server is old server

0x05: Proxy down (the bot could not connect to a proxy, which it uses to connect to Battle.net; suppose this could be either of the disconnected values though)

0x06: Bad Version (perhaps the bot does not support auto-updating its hash files, and the Battle.net server doesn't like the version (eg, version too old, unrecognized version); could be useful to see when a new product version has been released, and hashfiles need to be manually updated for services)

0x07: Bad Key (perhaps Battle.net has rejected a CD key and the bot does not have (or support?) autmoatically changing keys, or it out of new keys)

0x08: Server Down/Unreachable (perhaps the bot does not support automatically changing servers or all of the servers which is has are down or unreachable?)

etc etc, I could go one with other useless values...

Not sure what this is in response to, but it is a possibility if additional fields are added to bot status.

I wish to have support for storing a database on the server, probably in a different way than that of ZeroBot. I will contact you at your email address, then, since that's where you've requested this particular discussion to take place.

Though, I was under the impression that there were other bots that had supported such a feature.

E-mail is preferred since there will likely be quite a bit of exchange working out the details.  The internal database format is currently heavily geared toward Zerobot's flags based system, which is generally agreed to be a good design.  Other clients do use the database system, but they're all flags-based as far as I know.  (Though they assign different internal meaning to a given flag, which is fine since botnet doesn't care about the flags other than that they be alphabetic.  That requirement is mostly for convenience, since the flags can be internally represented by a 26-bit wide flags variable.)

IMO, the server version should change when it's being modified to support a new protocol version, changed when bugs are fixed, and etc. Additionally, IMO, it's the protocol version that should have changed when new features are added to it (such as the account management features in "server version" 0x02, and the "client supports X server version" and "client and server will communicate in 'server version' X" in "server version" 0x04).

I'm not saying that either of your intentions are invalid... it's just that they seem to be ambigous, with only one of them being updated.

I introduced protocol revision with server version 4; perhaps unfortunately, I didn't mention it to Skywing until a fair amount of code had already been written for it.  If you look over the pr1 spec when it comes back up, you'll see that switching from revision 0 (the default for legacy clients) to revision 1 causes the internal format of several messages to change, thus why negotiation must occur.  Additionally, the server only offers up certain types of new information to clients that indicate they expect it.  This is in part to deal with certain clients which have demonstrated a tendency to self-destruct when passed more data than they expect.  Skywing's concept of server revision is quite useful; however, as implemented, it didn't (IMO) lend itself to negotiation, which I wanted to support.  Thus, I created protocol revision.

Now that you mention it, I remember you telling me as such. Yet, I still beleive there should be an error code, instead of just "an error occured". Perhaps you could create a variable (since I don't know how the BotNet server is structured, I'll just say in or with the packet's context, or perhaps in the data received function and pass a pointer to it in the packet's parser), which gets set to 0 at the default return, or to an error code at any other return. Then, if the parser returns true, you pass that variable along to the protocol violation handler, else, you ignore the value. If you *do* do it that way, then be sure to set init the value to either 0 or "internal server error", so that if you forget to set it in the parser, you won't send along an invalid error code value.

Actually, if I add error code reporting, it'll probably be in the form of having the parser return 0 for no error, or nonzero on error.  If nonzero is returned, then the returned value is passed to the client.

[tA-Kane]

Probably so.  However, using nonstandard values already causes you problems in communication.  Some clients (in particular mine) refuse to accept messages not in strict compliance with the specification.

Programmers wouldn't be so "willing" to break the protocol spec if it was more specific on the specifics.

The parsing change is simple -- if you don't mind losing backward compatibility.  The server is supposed to retain compatibility with clients using the current botnet, which will become "legacy" clients when we switch over.  For a client to remain compatible with a legacy server, it will need to consider the protocol revision each time it tries to parse a message.  Not hard, but it is more trouble.

IMO, it's really not too hard to do backwards compatibility... Again, I would need to know more about the server in order to understand.

Identifying someone's gateway is primarily desirable for determining whether they will be able to affect your bncs environment.  If they aren't on the same gate as you, they can't -- doesn't matter which gate they are on.  I've never seen a client that couldn't figure out what IP it was connected to, so anyone supplying a bogus IP must be either a bad programmer, intentionally deceptive, or using a really sucky language.

Yes, sucky language indeed, which refuses to link to OTLib (Open Transport is required for domain lookups), and linking to any "standard library" would require that the library be either in the user's extensions folder or the same folder as the application, which just causes confusion.

Additionally, doing a domain lookup shouldn't be relied upon to do find out the NAME of the gateway. Suppose the lookup fails? Suppose it comes out to something like bne-watcher-01.battle.net? Sure it'll tell the user what gateway they're on, but can a bot automatically know that bne- is USEast? Maybe through some file, perhaps, but that's eww++. The best way is for the other bot to know what gateway it's on (whether told by the user or by doing a /whoami after SID_LEAVECHAT) and report that to BotNet.

If you have some other use for gateway name, please say so.

Sure! Use the gateway names to identify who's using what command (and who has access to what command). As such, any commands received from botnet will be "Account@BotNet". Additionally, you could then "link" (associate) BotNet accounts to Battle.net accounts, and then display the "main" account@gateway, and do command processing that way. Not necessarily an easy task, but quite a luxury if done right (it's very possible to do).

Unfortunate, but unavoidable.  Suggest an alternate value for that field that can't be accidentally spoofed by a user roving unusual channels?

Empty... blank... nil... null... none..., and use a different parameter to specify "Not logged on".

Zerobot has a fair amount of clientside support involved in this.  If I read the code right, the logic is essentially that if the channel is comprised only of friendly bots, Zerobot asks everyone else to bail out.  When the channel is comprised of only itself, it rejoins to reacquire the gavel.

That could be done via a bot command over botnet (aka interbot).

Not sure what this is in response to, but it is a possibility if additional fields are added to bot status.

A possible use of the cycle status, in relation to replacing the "Not logged on" in angle brackets for the channel text.

E-mail is preferred since there will likely be quite a bit of exchange working out the details.  The internal database format is currently heavily geared toward Zerobot's flags based system, which is generally agreed to be a good design.  Other clients do use the database system, but they're all flags-based as far as I know.

That's fine.

(Though they assign different internal meaning to a given flag, which is fine since botnet doesn't care about the flags other than that they be alphabetic.  That requirement is mostly for convenience, since the flags can be internally represented by a 26-bit wide flags variable.)

That might be fine for the BotNet server, but it's not fine for bot interoperability (as you've subtly pointed out). A standard should be set up for user flags.

I introduced protocol revision with server version 4; perhaps unfortunately, I didn't mention it to Skywing until a fair amount of code had already been written for it.  If you look over the pr1 spec when it comes back up, you'll see that switching from revision 0 (the default for legacy clients) to revision 1 causes the internal format of several messages to change, thus why negotiation must occur.  Additionally, the server only offers up certain types of new information to clients that indicate they expect it.  This is in part to deal with certain clients which have demonstrated a tendency to self-destruct when passed more data than they expect.  Skywing's concept of server revision is quite useful; however, as implemented, it didn't (IMO) lend itself to negotiation, which I wanted to support.  Thus, I created protocol revision.

Oh yeah, and there's THAT protocol revision as well. So, we now have *3* protocol revisions to worry about.

The one on the packet level (Protocol 'Version'; this is the one I was referring to, currently doing absolutely nothing except disconnecting the client if not 1).
The one specifying the server version (Server Version; this is the other one I was referring to, currently adds/removes certain packet support).
And, the one which is used to specify the expected format of packets (Protocol 'Revision'; which is the one you are referring to, also adds/removes certain packet support).

How many versions do we really need???

Actually, if I add error code reporting, it'll probably be in the form of having the parser return 0 for no error, or nonzero on error.  If nonzero is returned, then the returned value is passed to the client.

Fine with me, just as long as an error code is produced and transmitted to the client.

[Arta]

To kp:
Kane raises a good point by saying that an empty channel string could indicate that the client is not logged on. If that were implemented - or merely, allowed (afaik it's not currently) - no additional field would be required.

To Kane:

Since you seem to have a good handle on this, I wonder if you'd like to help improve BnetDocs' BotNet documentation? If you have any suggestions for things to change, or any specific things you think should be clarified, I'd be happy to do that. I'd be happy to reciprocate with a higher access level or appripriate credit if you wish.

[Arta]

Yes, it's back up along with the rest of vL.com, and no, I doubt anyone wants to implement IBP because it was crap to begin with and BotNet is better, so just add support for that.

[Kp]

Programmers wouldn't be so "willing" to break the protocol spec if it was more specific on the specifics.

A strict interpretation would be that anything not specifically permitted is not guaranteed to work or be allowed.

IMO, it's really not too hard to do backwards compatibility... Again, I would need to know more about the server in order to understand.

Server backwards compatibility is easy enough.  However, if message formats start changing, the new-format-aware clients must also support old format messages in order to handle older servers.

Additionally, doing a domain lookup shouldn't be relied upon to do find out the NAME of the gateway. Suppose the lookup fails? Suppose it comes out to something like bne-watcher-01.battle.net? Sure it'll tell the user what gateway they're on, but can a bot automatically know that bne- is USEast? Maybe through some file, perhaps, but that's eww++. The best way is for the other bot to know what gateway it's on (whether told by the user or by doing a /whoami after SID_LEAVECHAT) and report that to BotNet.

I'm suggesting that the reporting client not care at all what gateway it is on.  It merely submits the IP address to which it connected, and observing clients can use that address to figure out which gateway the reporter is on.  Also, I'd expect that the /whoami method will produce bizarre results (if it at all works) if you tried that on a bncs-emulator, since most of those are not greatly compliant.

Sure! Use the gateway names to identify who's using what command (and who has access to what command). As such, any commands received from botnet will be "Account@BotNet". Additionally, you could then "link" (associate) BotNet accounts to Battle.net accounts, and then display the "main" account@gateway, and do command processing that way. Not necessarily an easy task, but quite a luxury if done right (it's very possible to do).

Convention has mostly dictated that you simply keep one database per server cluster ([vL]West vs. [vL]East, for instance).  Also, aside from the war3/nonwar3 mangling issue, your linking idea doesn't require gateway identification IMO.

Empty... blank... nil... null... none..., and use a different parameter to specify "Not logged on".

Noted.  I'd been considering this, but again a compatibility issue is introduced.  Old versions of the server would take rather unkindly to a blank channel field, thus hurting client compatibility with old servers.

That could be done via a bot command over botnet (aka interbot).

It could, but cycling support works a bit better for that.  The point is moot anyway, since there are no longer any channels in which ops can regenerate.

A possible use of the cycle status, in relation to replacing the "Not logged on" in angle brackets for the channel text.

I won't remove old fields.  New ones may be created if there is sufficient merit, though.

That might be fine for the BotNet server, but it's not fine for bot interoperability (as you've subtly pointed out). A standard should be set up for user flags.

That's outside the scope of botnet server development.

Oh yeah, and there's THAT protocol revision as well. So, we now have *3* protocol revisions to worry about.

The one on the packet level (Protocol 'Version'; this is the one I was referring to, currently doing absolutely nothing except disconnecting the client if not 1).
The one specifying the server version (Server Version; this is the other one I was referring to, currently adds/removes certain packet support).
And, the one which is used to specify the expected format of packets (Protocol 'Revision'; which is the one you are referring to, also adds/removes certain packet support).

How many versions do we really need???

There actually is a logic to this.  Packet revision, as specified in packet header will likely change only if support for old clients is completely dropped.  Server version acts as an indicator of new features and whether protocol versioning is supported.  Protocol revisions reshape packets internally, and add information to the reshaped packets.