Uniting the Multiplayer community

[Yoma 0]

here's something to consider... the average person will not download something unless they absolutely have to. and this logic goes with yoma's current tool.

now, if somehow this was possible... to connect to a server, one MUST have the tool installed and running. this way, this forces a standard in the community to install ONE thing, which is the proposed addon synching tool.

once you have that in place, half the battle is won.

Actually: couldn't this be done by making an addon

PLEASE_INSTALL_YOMATOOL_WWW.YOMATOOLS.BE.pbo

and getting that signed. so the user actually gets the message when he tries to connect(joke)?

Anyway i think the best solution would be for BIS to simply allow the serveradmin to redirect the user to a webpage if he can't connect due to addon problems.

Then the user could be directed to a decent page explaining

-what addons he needs

-what tool he might need to install to download these addons

This simple trick would solve LOADS of problems, but it would need BIS to implement it.

[Yoma 0]

Also if this was to extend to addons I would perfer only working addons as there are too many poorly done addons out there, Im sick to death of players connecting with 10 addons lol

dont they have a clue that if the server does not have the addons they are using that massive confilcts will accure

then you kick them and they come back saying wtf

If such a system does happen I bet it will only do the Stock Game, but may give the admins auto downloads like the old OFP watch

Again BIS should implement a redirect webpage on kick.

This way you could explain stuff to silly users.

[maddogx 13]

Anyway i think the best solution would be for BIS to simply allow the serveradmin to redirect the user to a webpage if he can't connect due to addon problems.

Then the user could be directed to a decent page explaining

-what addons he needs

-what tool he might need to install to download these addons

This simple trick would solve LOADS of problems, but it would need BIS to implement it.

I would be against this. Getting redirected to a web page is not something I expect to happen when trying to connect to a server.

I would prefer if a server admin could define a custom in-game pop-up message that appears if a user cannot join. That way any info can be provided directly in-game. Of course you should be able to provide a link in that pop-up, so players can choose to go directly to the website, but it should not be mandatory.

Perhaps we should try lobbying BI for this kind of functionality.

[acadiancrusader 0]

Anyway i think the best solution would be for BIS to simply allow the serveradmin to redirect the user to a webpage if he can't connect due to addon problems.

Then the user could be directed to a decent page explaining

-what addons he needs

-what tool he might need to install to download these addons

This simple trick would solve LOADS of problems, but it would need BIS to implement it.

I would be against this. Getting redirected to a web page is not something I expect to happen when trying to connect to a server.

I would prefer if a server admin could define a custom in-game pop-up message that appears if a user cannot join. That way any info can be provided directly in-game. Of course you should be able to provide a link in that pop-up, so players can choose to go directly to the website, but it should not be mandatory.

Perhaps we should try lobbying BI for this kind of functionality.

rather then an engine function, couldn't something like this be created/added to a mission. like some kind of standardized script that won't allow a user to continue playing unless they follow the directions on screen and/or follow a clickable link...

just thinking out loud here....

[aussie dave 0]

I think we are going wrong here:

Clients shouldn't need to download anything to join a server, if they are running CA or CA;DBE1.

Clients that are running lots of AddOns that are not compatible are the problem and they need to remove them before they join a server and crash it.

Thats why we need a list of safe keys (AddOns) that server operators can allow on their servers.

I have a post on our ISP forums listing which AddOns are allowed on the servers.

http://www.gamingsa.com/forums/showthread.php?t=4442

[maddogx 13]

Aussie Dave, you are right. Clients should not need to download anything. And in this system they wouldn't.

The tool I am suggesting for players is merely an optional way of ensuring that they are starting their game with only valid addons installed. Players running stock ArmA are just fine without downloading it. They need no keys or programs.

The list of safe keys is the central point of my idea, and it's something I would like to see in the future. Everything around that is open to discussion. My original ideas are in my first post, and I believe they cover most of the pit-falls pretty well.

EDIT:

Here's a brief summary of what I would like to see in this system:

- a central authority that governs a list of trusted keys

- an easy method for server admins to get those keys installed and regularly updated on their server

- some guidelines for addon makers for creating and signing fully MP compatible addons

- an easy and optional way for players to make sure they can start the game with addons that are all validated by the trusted keys

^^ That's it. No player is forced to download any specific addons or software if he doesn't want to.

[Synide 0]

all your concerns could be easily addressed by BIS implementing a new feature of the ArmAServer.exe.

The DedicatedServer.exe could be launched in 2 modes.

Ranked Mode.

+When lauched in 'ranked' mode the .exe could read the 'server.cfg' configuration file for an array of ArmA only specific 'torrent trackers'.

eg. RankedTrackers[]={"",""};

+ The first tracker in the array list would be one hosted by BIS. If BIS's tracker is unreachable it would fall back of the next tracker in the list. A torrent tracker could be hosted by each of the community websites. An update to an existing torrent would be mirrored amoung all the rest of the torrent trackers. Any newly added torrent would again be mirrored. Mirrorring among all the trackers including the BIS hosted one would mean little to none in management and maintenance.

+ There could be multiple torrents existing on the tracker(s). For instance a 'ranked' torrent for GPMP play in Europe. A 'ranked' torrent for GPMP play in North America. A 'ranked' torrent for GPMP play using the HWM mod. A 'ranked' torrent for GPMP play using the VTE mod.... etc.

+ If you wanted this particular server to run as a GPMP European server you would acquire the torrent for this 'league' from any community website.

+ Next, the DediServer.exe would look for the name of a 'RankedServerTorrent="";' parameter in the server.cfg and load the torrent file it points to from the hard disk on the server. It could compare the checksum of this torrent file with the checksum of the same named torrent in the 'tracker' cloud. If different it could have a setting in the .cfg to indicate what to do. ie. automatically overwrite the local version of the torrent file or do not continue starting the dedi with this 'ranked' torrent and indicate to the server.log that the local ranked 'torrent' is out of date.

+ Next, the DediServer.exe would download the contents of this 'ranked' torrent.

The contents would consist of the .bikey files that this particular 'ranked' torrent relate to.

And, the torrent would contain one other type of file.

Say, a file called 'contents.txt'. For use later by a Yoma type tool. The contents.txt file would contain a list of the .pbo's that this particular 'ranked' torrent would have been created for and the md5 checksum for each of those pbo's.

+ The DediServer.exe would only load .pbo's from the 'Addons' folder and the <ModFolderPaths> that are signed with those .bikey files that have just been downloaded (or the the torrent was up to date then from the local Server hard drive).

The DediServer.exe wouldn't need to care about anything else at this point. All it should care about is loading stuff from pbo's.

Sounds like alot of extra bandwidth and lots of downloading and stuff right? The, trackers would be running huge numbers of torrents? The files downloaded in the torrents would be huge?

The answer to all those questions is - no.

The .torrent file would be a couple of kilobytes. The contents of the .torrent file would be the several .bikey files, again tiny and a contents.txt file, also tiny. The process would be blindly fast because all the hosted trackers would be swarming these very few tiny kilobyte files.

UnRanked Mode.

When starting the DediServer.exe in unranked mode it would not bother talking to the 'tracker cloud' or downloading anything. And, simply start and load all 'AddOns' .pbo's and all stuff from the <ModPaths> as usuall.

Clientside

On the client end of things Yoma's tool comes in and discovers if a given server is running 'Ranked' or 'UnRanked'.

If 'ranked' then it acquires the .torrent and grabs the .bikeys+the contents.txt.

It preprocess the Addons and Mod folders firstly spurning anything that is not signed with the .bikeys.

Then it checks each of the .pbo's left have the same checksum's as the contents.txt file.

If all is ok, then it launches the Game for you... all done.

If BIS did not want to participate in anyway then all of the above could be accomplished by the community alone and a couple of community built tools without any alterations to the Dedi.exe or the server.cfg on BIS's part.

However, in my opinion, it would be better if BIS could implement it through the Dedi.exe and the server.cfg.

Hell, Yoma's tools are doing pretty much all of this now.... !

It just needs that one step more...

Now, who decides on what the contents of a given 'ranked'.torrent should be? Well, that is up to the Mod maker or could a community at large.

Yoma's tools could do all this... the only buy in is from people hosting torrent trackers to support it. And, for the life of me I can't work out whay the community is not .torrent'ing all it's content.

The hosted torrent trackers would not be 'hosting' anything but small kilobyte .torrent files specifically relating to ArmA content only... so, would have nothing to do with the 'torrent' scene on the wprld wide web.

just thoughts... s'up to you if they are of any use...

cheers.

[maddogx 13]

Very good idea Synide, but I believe it would be more relevant to servers that wish to run a specific mod, than to servers that simply want to ensure compatibility for general multiplayer. I could imagine your torrent idea working for something like ACE or SLX, where people who try and join a modded server could opt to download the mod if they don't have it.

Your idea is mostly based on the premise of "downloading addons that are missing", while mine is based on "removing addons that are not valid". Those are two different concepts that aren't really compatible.

Nevertheless I find your idea quite intriguing. It could definitely be worth having that kind of functionality in ArmA.

[Synide 0]

Your idea is mostly based on the premise of "downloading addons that are missing", while mine is based on "removing addons that are not valid". Those are two different concepts that aren't really compatible.

Nevertheless I find your idea quite intriguing. It could definitely be worth having that kind of functionality in ArmA.

no, no it's not... i must have given you the wrong impression... the thoughts i posted above were meant to give the impression of validating and weeding out stuff on a client & server that would end with the result of a General Purpose Multiplayer environment.

the thoughts i posted were meant to highlight that it would be entirely possible to cater for your requirements and mod requirements as well... obviously, i didn't get it across well enough... try giving it another read or I could draw a diagram I guess...

Let me paint you a picture with reference to stuff in your first post...

Let's say I create an Addon of a new whizzy tank... it's doesn't really fit into your GPMP scheme so I sign it with my standard signature and not my syn_gpmp signature.

All, is good and well I release the addon and people put it in there mod folder of other Synide stuff or in a general addons modfolder or maybe even drop it in the BIS Addons folder.

Now, They start a Yoma launch program they click on there favourite server GPMP server.The tool, discovers that server is currently running say as 'Europe_GPMP' ranked.

So, Yoma's tool looks at a yoma.cfg file and finds a list of ArmA Community torrent trackers.

The first one it tries in the list is currently down so it goes to the next and it's up and running. So, it asks for the Europe_GPMP.torrent. 2kbytes.

Once it gets the torrent it discovers that 1. the actual .torrent is exactly the same as the one currently on the persons computer. 2. It also, dicovers that the contents of what that torrent is for is also exactly the same as whats on the persons computer.

The contents of the .torrent are 15 .bikey files and a contents.txt file. The 15 .bikey files are currently what the European ArmA community has agreed on are the xxx_GPMP.bikey's that should be allowed on server's and clients alike to set a level playing field for MP gameplay.

So, Yoma's tool then checks all .pbo's on the person's computer that are about to be loaded based on there Addons folder(s) using a spawned shell process and making use of the 'DSCheckSignatures.exe' from BIS and using the 15 Europen_GPMP .bikey files.

Any, .pbo's that don't make the grade are 'temporarily' renamed or possibly even shifted out of the ArmA game folders.

Now, as an added bonus Yoma's tool has the contents.txt file and so can also double-check (if desired/necessary) that the .pbo's making up the 'European_GPMP' requirement are present on the persons computer and have matching md5 checksums, this could be an optional thing.

At, this point the Yoma Launcher could then either go ahead and Launch ArmA safe in the knowledge that all the pbo's that are about to be read by the persons ArmA.exe are going to be acceptable to use on the server just requested and 'fit' in with the 'European_GPMP' ranked play requirements.

get it?

Now, because my whizzy tank.pbo is not signed with my xxx_gpmp.bikey it didn't make it through Yoma's tool and so got renamed and consequently when the persons Game.exe loads that whizzy tank.pbo doesn't get loaded.

Now, because the mission I'm joining on the server was created with only European_GPMP flavour .pbo's I'll have no problems with the mission calling for stuff on mine & everyome else's computer that isn't there or even up-to-date.

you could achieve all the above without using .torrenting technology code as well...

So, to summarize... the above would facilitate your desire to split the signed addons base into 2 categories. 1 category for GPMP type addons and 1 category for everything else.

[Synide 0]

Also, I'm trying to fathom what sort of content an Addon maker would create that did not require the server & or the other players to have it as well would look like?

Can you give an example of a current GPMP type of addon that is out there?

Or what an Addon of this type might do or look like?

[maddogx 13]

Thanks for the explanation Synide. I believe I understood you correctly now. The torrent trackers are a neat idea if used as you say.

As for examples of GPMP compatible mods:

XEH - Pretty obvious, as it only provides a framework for event handlers. No content is broadcasted over the network, so this addon is 100% OK.

Maddmatt's ArmA effects - Pretty much only replaces the explosions and other special effects in ArmA with higher quality ones. Again, nothing is broadcasted over the network.

Sound replacement mods - Again, nothing transmitted. No problems.

Kegetys Lowplants - Same story.

[[frl]myke 14]

Hi, i'm pretty new to addon making (although i'm pretty well in scripting) so please don't rate my 2 cents too high...just a thought i had while cross-reading through this topic.

I see you're talking about the technical possibilities if it can be don, how it can be done, what can't be done and so on. Well, at this part i can't say anything helpful because this is far beyond my knowledge.

But, IMHO, another problem as the technical aspect is the publicity aspect.

Players should know there's a tool (however it finally works) which is meant to be used when playing online, with addons that aren't cheats for sure.

They should know what they have to do and where they can do it.

Of course, as mentoined, it would need some sort of "commitee" which defines key's as "GPMP approved key".

So maybe from this point of view, a cooperation with major arma fansites and supportsites would be a good way to become more than a news entry at these sites but a fully supported part of these sites.

So a wide support for this project by arma sites i see as mandatory for it.

My 2 cents. As said, don't weight it too high.

[Yoma 0]

Ok so do we want some kind of dictatorship telling us "OH I THINK THIS IS INDEED A GOOD ADDON LETS SIGN IT" signing only dull clientside addons. What would that solve exactly?

It would most likely render you a list of how many addons?

People would want to use other addons anyway. The point is a lot of these addons function, but ONLY in given combinations. That my dear friends you will never be able to solve i think.

On the torrent idea: i don't know about you guys but i'm not gonna be gaming AND spending all my precious bandwidth on upping/downing torrents meanwhile...

Torrents are great when you have a gazillion users, but they are a really bad idea when you only have 1000 users...

Remember the message we all tell guys with low bandwidth on servers: Stop Emule!

EDIT: ok if you only torrent the keys then maybe it may work.

[Yoma 0]

Anyway i think the best solution would be for BIS to simply allow the serveradmin to redirect the user to a webpage if he can't connect due to addon problems.

Then the user could be directed to a decent page explaining

-what addons he needs

-what tool he might need to install to download these addons

This simple trick would solve LOADS of problems, but it would need BIS to implement it.

I would be against this. Getting redirected to a web page is not something I expect to happen when trying to connect to a server.

I would prefer if a server admin could define a custom in-game pop-up message that appears if a user cannot join. That way any info can be provided directly in-game. Of course you should be able to provide a link in that pop-up, so players can choose to go directly to the website, but it should not be mandatory.

Perhaps we should try lobbying BI for this kind of functionality.

Website or link, it's the same for me: the basic goal is just having a means to inform the gamer what he needs to do to play on the server.

This could be a signup page for a clan, an explanation page, anything really.

The point is: if people don't know people can't work it out right now, they need more info. The reason i would open the website allready is simply because then users would actually LOOK AT IT.

By the way, if all you basicly want to do is spread out some approved keys: why don't you simply make a yomasync with only keys for server admins? Then server admins could sync from there?

The only thing that would be needed then would simply be a tool that checks if all your addons are correctly signed.

Honestly i'm starting to think the payoff of this project would be too small versus the amount of work that would go into it.

There is no way at all you can force clients into checking their addons before connecting.

If i just made a tool to rip out nonstandard addons in the bis/addons folder, then all players really need is my tool.

I'm not talking about server admins.

I'm not gonna write a tool that dumps 95% of a players addonscollection because some guys think they are god and only their approved addons should be used.

For example when i look at my game folder it has about 20GB of addons. What are you guys suggesting: that when i want to launch the game on a given server i'm going to rename/move 20GB of addons?

Why dont you simply do the following:

-make a yoma addonsync for server admins that hosts all the approved mods you want to use

-and that also hosts the approved server keys.

This way server admins could sync their keys and maybe even some addons in an easy fashion.

The difference in this approach is that you can start doing it NOW.

This way you can look if what you want to do is managable. Before starting to code off in all directions with some very fancy idea's that will most likely not be realisable. One of the things you don't think of in this context is freedom. When you limit freedom it goes away. That's exactly what's nice about Yoma Sync atm: you're free. That's also why people use it. "It helps me, but still i'm free".

Another thing: how does one check if an addon is signed with key X without using Arma.exe? Because if that's not possible we can ditch the whole client side part.

[Synide 0]

@Myke... all true...

@MadDogX... another thing I neglected to stress was... the above examples I gave of a possible senario were based around a Yoma type of tool.

I think it would be much better if BIS implemented a predominent part of this... it's much cleaner if a starting up ArmAServer.exe queried the server.cfg file for 'contact' details relating to ranked torrent hosters... they are processing the file at startup anyway. Also, I'm sure that they could implement a bit of .torrenting capable source into there current code base relatively easily. And, they are already scanning the .pbo's upon launch so it's not difficult for them to only load .pbo's with certain keys.

Then all a Yoma type tool would be required to manage is the aquisition of or validation of the clientside stuff... but, again I'm sure BIS could quite easily alter the Game.exe source code to not process .pbo's based of a list of keys if launched in 'Ranked' mode.

This then would only leave the community tool responsible for acquiring any missing content or pre-Game-launch checking if the server being connected to is detected as 'ranked'.

Also, the whole senario provides the ability for the community to have a 'fully ranked' torrent for say Europe_GPMP.torrent which might currently have say 4 .bikey's in it and the contents.txt might have 20 .pbo names with there respective md5 checksums. There might also be a 'proposed' Europe_GPMP_May2008.torrent with the same 4  xxx_GPMP.bikey's as the current 'fully ranked' torrent plus maybe a new xxx_GPMP.bikey that a new addon maker has released and the contents.txt file included might have 24 .pbo's detailed inside it with there respective md5's. This torrent might represent community proposed trial .pbo's plus the current 'fully ranked' ones from the Europe_GPMP.torrent.

The good parts about the whole senario is that with this setup... you have built-in redundancy. All the community torrent hosters are broadcasting the .torrents, they would also be seeding the .torrents and you could also have all the Game servers seeding the .torrents as well... If you have a 100 seeders world-wide seeding these ranked.torrents (which at most would be a few kilobytes in size each... eg. a .torrent of 4 .bikey files and a contents.txt would be about 5 kilobytes) then no given server is under load, it could even be an intermittent thing.

The above musings also provide for largely transparent maintence free operation, little requirements on the part of users and SA's if implemented well...

The whole senario also offers oppotunities for future initiatives that my present themselves from out of it's usage...

just a few more musings and thoughts to add in...

@Yoma... sorry for using your name in vain so much in the above posts...

Oh and MadDogX, sorry for sort of chiming in to this extent... but I have strong feelings on the 'topic' of what the future holds for Addon management initiatives.

[Yoma 0]

NP, it's my own fault that my name has become a program

[Synide 0]

hmmm... you posted while i was typing... interesting thoughts... yoma, although I aplaud your constructiveness regarding your addon sync tools... I could just as easily create them myself... I'm not suggesting you code any of the above... I'm not suggesting I code it either... I'm just throwing ideas out there...

no one is suggesting and authoritarian, big brother approach... no one is suggesting that you create a tool that HAS to rename the majority of 20Gb's of datafiles just so you can play on a server... as I mentioned above... the best senario would be for BIS to implement something...

Many online multiplayer games provide a mechanism for playing on 'standardised' servers. Also, you may have missed the parts about how easy it would be to not have to subsribe to any of this...

Also, you referred to emule... and sucking up bandwidth... these files would be miniscule... literally... if 100 or 1000 servers worldwide are seeding the 5 kilobytes of of data i would imagine that you would not even notice it's happend...

Your last question here I answered further up... It's understandable you missed it in the crap amount of wordage...

BIS currently provide the 'DSCheckSignatures.exe'... for checking pbo's with a given .bikey file... it's sitting right there on your computer already probably... if not, you can download it from the Biki... it's been out since day one of the tools release I think... can't remember now... I'm surprised you are not fully aware of it already.

Much of what I mubbled about above I reckon could be done on BIS's side if they were inclined...

Quote[/b] ]This way you can look if what you want to do is managable. Before starting to code off in all directions with some very fancy idea's that will most likely not be realisable.

Jeez, If I choose to dedicate myself to creating this senario I could do it... What I'm proposing is not hard to whip up in C++ or C#. The reason I don't is because I prefer to spend what time I do have available for ArmA related stuff doing the things that I want to do...

But, the main reason I wouldn't spend my time on coding this all up is that really... I don't play multiplayer anymore... I'm don't really care if there is or there isn't simple mangement initiatives in place for the future of addons... or currently either.

I don't think you've read what I wrote very well... I know in amoust all this wordage that it seems to be complicated and big... but it's not... it's rather simplistic actually...

I've spent the time to throw some ideas out there regarding MadDogX's initial foray into the topic... they are just thoughts and nothing more...

There are LARGE number of very, very capable coders in and around the ArmA community... most of them have little enough time as it is and to spend it on a project like this is probably a more accurate reason for it not getting done - time.

Quote[/b] ]

One of the things you don't think of in this context is freedom. When you limit freedom it goes away. That's exactly what's nice about Yoma Sync atm: you're free. That's also why people use it. "It helps me, but still i'm free".

Well, golly... really? You honestly believe that I fail to appreciate the context? And, think of ways to ease the labour of conformism and provide freedom for addon makers and therefore by proxy game players when it's comes to the 'context' of ArmA?

I don't know how I could have painted a more detailed picture above of how simplistic these senarios would be to implement and how they could be used to 'free' the Admin of alot of management & free the player from alot of management...

So, I think all up I have said enough on the topic... I know, I know... sometimes I talk so much rubbish it's painful...

But, lastly - no i'm not interested in coding it... as far as I'm concerned I have better things to do... and family look after.

I'm simply making some suggestions about what could be done... there is no harm indeed with throwing ideas around... and some with the ability and the spare time might be inclined to take some of them on board...

[Yoma 0]

You're absolutely correct about the BIS part. Maybe if they find the time for it they'll code something like that (the 2 server and client modes)

I'm just a bit grumpy today, I like my job but the company I work at is doing very bad (not my fault at all) and it's likely going to hell...

[maddogx 13]

I don't mean to offend anyone, but I think people aren't reading my posts properly.

Yoma, you seem to be taking this whole idea the wrong way. You say I am trying to "limit people's freedom" and that they want to have the freedom to use whatever addons they want. Well, why shouldn't they? If someone wants to use hundreds of different addons, why should I object? My proposal of governing addons is limited to a very specific situation, where only certain addons can be considered safe to use.

Fact is, people should not be using certain addons on public servers. Period. This is something that should be clear to anyone who has ever played on a public server, and it was proven to me again just a few hours ago while playing Warfare with friends. People are joining servers with addons that cause errors, and can even make the server or other players crash. It wouldn't be so bad every once in a while but whenever a server fills up to at leat 10-15 people you can be sure that at least one clever fellow will be using some kind of custom markers or weapon packs. Your everyday ArmA player  just doesn't know what he can use online and what he can't. So why not give him an easy way of finding out?

Another fact is, signature checking on servers nowadays is all over the place. Some admins do it, some don't, some only do certain keys, some sign addons themselves etc. etc. You never know whether you can join a server using completely legitimate addons - and when you can, you can also be 90% sure that the server doesn't use checking at all.

When I load up the game I want to be able to look at the list, see what servers I can join without myself or others causing any addon-related problems and just have a good game.

I hope to achieve nothing more than that.

[Yoma 0]

Again forget all my grumpy words, i'm just a bit frustrated by other stuff.

I'm pretty sure the goal we are trying to get to in the end is the same. What i do want everyone to know is that there allready is a way of doing this, it's not the best by far, but it does work. Try connecting to kellys with a heap of shitmods, it won't work. Then use my addonsync tool and connect with only the mods listed, it works.

Sure there are better ways and surely my tool is only part of the entire solution, but it does work and we need to get that message across to many people.

Anyway i'm still interested in helping the "keyspreading" stuff.

Again i ask the question: how do i check generically if a given mod is signed with a given key.

If we could sort that out we wouldn't need to list mod hashes and it would save a lot of trouble.

Hey this is my first post in X64 Vista!

I'm off to installing a lot of patches,drivers and Arma.

[=jps=sgtrock 4]

I've read through this whole thread and my gut reaction is that the proposed central repository isn't quite the right way to do things.  I hope I can articulate my reasoning well.  

I've been using free and open source software (FOSS) for various purposes for about 15 years.  I've also been hosting gameservers on the Internet off and on for nearly as long.  I've hosted a pretty wide variety of servers from at least 6 different vendors.  All of those gameservers have been Linux.  I and the admins that I've granted limited rights to have banned dozens, if not hundreds, of griefers over the years.  In all that time I've had exactly one break-in (due to one of my admins using a weak password).  I'd say I've got enough battle scars to have a pretty good idea of what works and what doesn't.  

That breadth of experience has taught me some painful lessons over the years about server administration in general, gameserver administration, and what tools are necessary for providing a solid experience for your players.  Sadly, BI's inexperience with the rough and tumble world of public Internet play meant that the first ArmA release was lacking in many critical respects from a security perspective.  To their credit, they've done a lot to make things much better.

I had originally written a long post detailing what I thought was where they still had some holes.  However, as I thought about things a bit more, I slowly came to the conclusion that they've already provided most of the tools that we need.    

In my view, what is currently lacking can be summed up by this from MadDogX:

Quote[/b] ]Fact is, people should not be using certain addons on public servers. Period. This is something that should be clear to anyone who has ever played on a public server, and it was proven to me again just a few hours ago while playing Warfare with friends. People are joining servers with addons that cause errors, and can even make the server or other players crash.

...

When I load up the game I want to be able to look at the list, see what servers I can join without myself or others causing any addon-related problems and just have a good game.

I hope to achieve nothing more than that.

Unfortunately, I don't think that the proposed central repository gets us any closer to meeting that goal.  I think without realizing it, MadDogX points out why in the same post:

Quote[/b] ]Another fact is, signature checking on servers nowadays is all over the place. Some admins do it, some don't, some only do certain keys, some sign addons themselves etc. etc. You never know whether you can join a server using completely legitimate addons - and when you can, you can also be 90% sure that the server doesn't use checking at all.

Not to mention checking files is also all over the map.  Many (most?) servers don't seem to enable it because it can slow the connection process so drastically.  Yet this is probably one of the more effective ways to stop some of the worst cheats.  It's obviously not bulletproof because it still depends upon trusting the client to properly report its results.  This violates one of the key tenets of network security; "NEVER trust the client."  Still, forcing an MD5 or SAH1 hash of files at the time of connection isn't completely useless.

From my point of view as a server admin, what's missing at this point in time are two functions.  

The first is some way to inform someone why they were disconnected.  The suggestion to redirect them to a Web page is a good one.  However, if we do that I think it needs to be an in-game connection instead of attempting a call to open a browser on someone's PC.  I don't know anything about ArmA's scripting language, so I don't know if this is something that can be done by a modder or not.  What I would suggest is that if it is possible, it should work something like this:

<ul>Player connects

<ul>Server downloads a small script that includes

<ul>The list of approved mods for comparison

<ul>The code to perform the MD5 or SHA1 check along with the correct, precreated hashes for comparison (helps minimize the need to trust the client).

<ul>The code to create the disconnect message if the connection process fails.

<ul>The downloaded script checks to make sure that only pre-approved mods are loaded.

<ul>If the check passes, Player connection proceeds as normal.

<ul>If the check fails, the redirection code is triggered.  At minimum, this should put some text in the middle of the Player's screen that tells him why he's being disconnected.  If it's due to having unapproved mods or failed hash checks, tell the Player exactly what failed.

<ul>The downloaded script runs the hash checks and comparisons.

<ul>If the check passes, Player connection proceeds as normal.

<ul>If the check fails, the redirection code is triggered.

The other function that's missing is some way to add lots of admins without having to give them all passwordAdmin.  Ideally, I'd love to have some way to create pools of admins with map change, map change/kick, map change/kick/ban privileges.  

This solves multiple problems for me.  First, it gives me a way to guard my server without having to grant unlimited rights to people who may not deserve it.  Second, it gives me a way of promoting admins as they demonstrate that they deserve it.  Third (with logging), it provides a way of resolving conflicts when someone asks to have a ban lifted because I can go back to the admin who did the action.

This kind of administration mod has been available for a long time for Quake 1, 2, 3 engines, Unreal engines, Half-Life engines, etc.  Sometimes it's created by the vendor (Unreal).  Sometimes it's a modder created addon (Quake and HL).  Quite some time ago I asked on the Modding board if anyone was interested in creating such a mod.  Sadly, I got no response.    Is there anyone reading this thread who thinks they could write such a program or script?

(Edit)One thing that I forgot to mention is that it sure would be nice if there were some way of displaying more detailed information about servers in the in-game browser. Having a list of pre-approved mods instead of just the one that is actually running, a complete list of who is on a server instead of just a few, etc. It would help people find servers that they want to connect to. (/edit)

[maddogx 13]

SgtRock, good post and valid points. Some comments from me though:

Quote[/b] ]Not to mention checking files is also all over the map.

Signature checking and file checking is actually the same thing. PBO files and their corresponding signatures belong together, and the file/signature check is basically there to check if the data in the file hasn't been changed.

As for the idea of the central repository - surely it's not perfect, but it's a start. At least it would (if done correctly) put players and servers on the same field. Of course a robust implementation would be required for this to work, but that's basically what I'm trying to work out.

So far the feedback on this topic has been pretty unsatisfying for me, since the responses are mainly suggesting complete alternatives rather than improvements or constructive suggestions, so I'm guessing the idea won't lift off. Additionally, most of the alternatives people are suggesting in this thread are based on BIS themselves making more or less extensive changes to the dedicated server program. Of course this would be ideal, but we as a community do not have any control over that.

So many people are complaining about "the anti-cheat system getting circumvented" and "servers crashing constantly" which is (from my perspective) mostly due to a lack of cooperation in the community to create a compatible and safe multiplayer environment. So long as nothing happens to remedy this, the situation probably won't change.

[=jps=sgtrock 4]

Quote[/b] ]Signature checking and file checking is actually the same thing. PBO files and their corresponding signatures belong together, and the file/signature check is basically there to check if the data in the file hasn't been changed.

Are you sure about this?  I've always understood a signed file check has minimal checks at best.  Someone along the line in this thread pointed out that some modders were re-using signature files.  That shouldn't be possible if a signed file had any changes.  A signature check and be as basic as just verifying whether or not a signature itself is valid without necessarily comparing it to the file it is supposed to represent.

I thought the file check routine was actually a hash comparison of matching file names on the client and server.  That's a very different process.  

Right now, I've got the following lines in my server.cfg:

<table border="0" align="center" width="95%" cellpadding="0" cellspacing="0"><tr><td>Code Sample </td></tr><tr><td id="CODE">

verifySignatures=0; //Signature Verification broken in 1.08

// onUnsignedData="kick (_this select 0)";

...

//Cheat detection

checkfile=0; //1=slow 0=default

onHackedData="kick (_this select 0)";  //auto ban hacked addons

onDifferentData="kick (_this select 0)"; //auto kick modified files

checkfiles[]=

{

       "dta\bin\config.bin",

       "dta\bin\config.cpp",

       "Addons\wheeled3.pbo",

       "Addons\weapons3.pbo",

       "Addons\A10.pbo",

       "Addons\weapons\config.cpp",

       "Addons\weapons\config.bin",

       "Addons\wheeled\config.cpp",

       "Addons\wheeled\config.bin",

       "Addons\tracked\config.cpp",

       "Addons\tracked\config.bin",

       "Addons\sara\config.cpp",

       "Addons\sara\config.bin",

       "Addons\air\config.cpp",

       "Addons\air\config.bin",

       "Addons\miscUS\config.cpp",

       "Addons\miscUS\config.bin"

};

If what you say is correct, why are both sets of lines necessary? (forgetting the comment about signatures being broken in 1.08, anyway)

[maddogx 13]

I'm not sure about those two different settings in the server config. Perhaps there are indeed two different file checks going on, or maybe the old checkFiles method is no longer used.

Regardless, I'd like to clear up some misconceptions:

Quote[/b] ]Someone along the line in this thread pointed out that some modders were re-using signature files.

If they are, then they're undoubtedly doing something wrong. A signature file is created specifically for a certain version of a .PBO file. The two belong together, and it is not possible to use the same signature file for another .PBO or even a modified version of the same .PBO. (Although it is possible to sign the same .PBO with different keys.)

Quote[/b] ]A signature check and be as basic as just verifying whether or not a signature itself is valid without necessarily comparing it to the file it is supposed to represent.

Wrong again. The signature itself is nothing without the .PBO it represents. Checking a signature on its own does not make any sense in a data-security aspect.

[=jps=sgtrock 4]

OK, we clearly have a disconnect at some point. Tell me, what do you think a signature file is? What does it represent? How is it associated with the file that it supposedly was generated from?