Jump to content
fred41

Arma Server Monitor (very small, but useful)

Recommended Posts

Thanks for the prompt reply again.

second (i am assuming, your ARMA2 server doesnt run on the same system as your ARMA 3 server):

- it seems the "Microsoft Visual C++ 2010 Redistributable Package" is not installed on your OS where ARMA2 is running!

It IS running on the same system, which is why it's puzzling about the C++ stuff being missing. However, reinstalling it from you link has fixed the problem! Thankyou and awesome.

Now if only I could remote view it.....

Just to sanity check how I'm running the client on my home PC....I've taken the ArmaServerMonitor.exe from the download, and created a shortcut to it. In the properties of the shortcut I've edited the "target" line to be:

"D:\My Desktop\ArmaServerMonitor.exe" -client -h144.76.28.77 -p24000

(not hiding my IP address this time, as it's in my sig anyway)

....and finally.....any way to monitor more than 4 servers? Got a big powerful box and plan to run 5 or 6 eventually between Arma2 and Arma3.

Mucho thanks for your help in this.

Share this post


Link to post
Share on other sites
"D:\My Desktop\ArmaServerMonitor.exe" -client -h144.76.28.77 -p24000

... this ASM-client command line looks perfect.

I tried to connect your ASM-server from my local ASM-client, got error 10060 (timeout).

Wireshark record show me, that there was NO answer packets received from your side.

Either your ASM-server was not running OR/AND your firewall is still blocking the port 24000.

Did you tried ASM-server and ASM-client, both together, local on your server machine?

Never give up :)

Fred41

Edited by Fred41

Share this post


Link to post
Share on other sites

Fixed it!!!

When I was messing with the ports on the server firewall, I was a bit blinkered to port 24000 and I'd not only set both inbound and outbound rules to open this port, but I'd set the remote port to be 24000 too. Reset it to any port, and I can connect remotely now. Thank you for your patience with me.

And now for some feedback/suggestions if I may:

1. put a password on it. Maybe in the server side settings have something like:

ArmaServerMonitor.exe -server -n1 -amypassword -h127.0.0.1 -p24000

This will stop anyone looking at your server data if you are not currently connected to it remotely. (As IP address is easily findable, and most idiots (myself inc) won't change the default port)

2. Can the window be made resizable? Ideally vertically to add more server monitor windows (or less if you only have one or two servers) but mainly horizontally, so you can scale how much of the graph you want visible.

3. Have a 'double click' to toggle a minimum view, without the graph. Leaving just the column of current values that can be positioned conveniently on the desktop. Also maybe a 'always on top' option?

4. Put a legend on the right click. Maybe when you right click on the numbers list on the left (where you get the transparency option) also list what each line means, so older people like myself can get a reminder!

I'm so looking forward to weeding out the system intensive missions and ensuring my servers run a lot smoother with this.

Share this post


Link to post
Share on other sites
Fixed it!!!

... really glad to hear it :)

Thanks for your suggestions, this are a lot good ideas.

Related to password protection, i think you can protect your (not really sensible) server performance data good enough, by changing the default port to something else.

In combination with restricting the number of clients, this should provide a appropriate security.

The current user interface, you are absolute right here, is a bit rudimentary, but at least it works :)

There are plans for a web browser interface in the future, which could make ASM a more nice looking toy.

But i will think, how to implement some of your ideas in the current (Delphi 2006) ASM as soon as possible.

I'm so looking forward to weeding out the system intensive missions and ensuring my servers run a lot smoother with this.

I think for this kind of usage, ASM will really help you. A next step could be, optimizing your favorite missions and verify your progress with the help of ASM.

Greets,

Fred41

Share this post


Link to post
Share on other sites
Fixed it!!!

When I was messing with the ports on the server firewall, I was a bit blinkered to port 24000 and I'd not only set both inbound and outbound rules to open this port, but I'd set the remote port to be 24000 too. Reset it to any port, and I can connect remotely now. Thank you for your patience with me.

I have the same problem (can't remote connect to the server -> connection timeout). I double checked my firewall rules and TCP Port 24000 is allowed in both directions (and remote port to any). Windows Server 2008. Even tried to allow all ports für the monitors ".exe". Any suggestions?

Share this post


Link to post
Share on other sites

... ASM-server is listen on one local port for TCP connection attempts (default port: 24000).

Assuming you use the correct set of ASM command line params (for server and client),

all you need is to open your firewall for this ONE selected port for INBOUND connections.

This normally means, you have to create only ONE new INBOUND rule, in your advanced firewall settings, like this:

profile: public

action: allow

protocol : TCP

LocalPort: 24000 (or what port you prefer)

(all other is ANY or default)

Hope i could help you. If not, post your commandlines, both server and client side.

Fred41

I have the same problem (can't remote connect to the server -> connection timeout). I double checked my firewall rules and TCP Port 24000 is allowed in both directions (and remote port to any). Windows Server 2008. Even tried to allow all ports für the monitors ".exe". Any suggestions?

Share this post


Link to post
Share on other sites

I start the server with the default parameters (I also tried no explicit params):

-server -n1 -h127.0.0.1 -p24000

Locallly I start with (I masked the IP):

-client -h114.76.xx.xx -p24000

Inbound rule for 24000 on TCP (with remote to any) is still activ.

Problem seems to be serverside, as other people can't connect to the server too.

Share this post


Link to post
Share on other sites

... your params looks correct.

Try the following:

Start the first ASM instance without params (defaults to: -server -n1 -h127.0.0.1 -p24000) local on server device.

Start the second ASM instance local on your server device too, with: -client -h127.0.0.1 -p24000.

If this connection works (Request/Update in title line of ASM), then you know the problem is still in your firewall(s) configuration.

Let me know,

Fred41

I start the server with the default parameters (I also tried no explicit params):

-server -n1 -h127.0.0.1 -p24000

Locallly I start with (I masked the IP):

-client -h114.76.xx.xx -p24000

Inbound rule for 24000 on TCP (with remote to any) is still activ.

Problem seems to be serverside, as other people can't connect to the server too.

Edited by Fred41

Share this post


Link to post
Share on other sites

UPDATE: userinterface improvements, thanks zach72 for very good ideas

  • history graph on/off switch (popup menu)
  • number of displayed instances, selectable range 1..4, (popup menu)
  • stay on top on/off switch, (popup menu)

For this update, you only have to update the ArmaServerMonitor.exe binary from my github repository.

ENJOY :)

Share this post


Link to post
Share on other sites

Heyho,

I am on a different network today and the same settings seems to work now. So it's probably related to my local network hardware (besides both networks have the same hardware). I will look into it as soon as I am back home. But now I know where the problem is located.

You are using a injected FSM to read the data from the server? So it should be possible to inject code to ArmA too. Can you write two feature: A chat for posting messages on the server without using BE-RCON (maybe as HQ identity) and a way to inject code to the server? Should be easy to execute a string with spawn compile "String". This would make a great addition.

Edited by NeoArmageddon

Share this post


Link to post
Share on other sites

... i wouldn't call it injection, there is just a autostart function define in CfgFunctions, used to launch fn_ASM.fsm at mission start.

This FSM reads/measures periodical some performance values from inside the DS and WRITES the data in a shared memory area (in swap file).

This way different processes (DS -> ASM) can exchange data very fast, currently in one direction.

I think, using this monitor tool to control your server (and maybe connected clients), would exceed the primary meaning of a monitor tool a bit,

even if technical possible.

But the idea is very interesting, maybe i rethink my current attitude later :)

Thanks for your feedback and recommendation,

Fred41

Share this post


Link to post
Share on other sites
But the idea is very interesting, maybe i rethink my current attitude later :)

Sounds good. I could assist with server side (SQF, FSM) scripting if needed.

I think a lot of people are also interested in accessing Monitor-Data via browser. It should be possible to read the swap file within PHP, shouldn't it? Maybe a webserver can access the same data from the FSM/Swap wuithout the need to proxy with the actual monitor programm (as mentioned early in this thread as a feature suggestion).

mfg

Neo

P.S. I also found the mistake with the remote-monitor. I double checked the wirefall setting but I didn't double checked the IP I tried to access :D Everything works now.

Share this post


Link to post
Share on other sites

Hello.

Awsome tool you got there, using it alot :) Thx for your work mate.

Now, am i overlooking something? I cant seem to find a key for the .pbo, to use on my server. Im running with sig verify, so my HC (when loading with ASM) gets kicked.

Would you be able to sign the addon mate? Or am i simply overlooking the key somewhere hehe?

I want to monitor both the server and HC but atm it doesnt seem possible with sig verification turned on :)

Hope you can "fix" it, or point me in the right direction, if im missing it somewhere :)

Share this post


Link to post
Share on other sites

You don't really need to monitor the HC. It has no real "simulation" so it's FPS is not related to anything except the dedicateds performance. For monitoring the HC's AI load, you can have an eye on "AIR" in the monitor. It represents the HC's and players local AI.

Share this post


Link to post
Share on other sites

Hi Byrgesen,

NeoArmageddon said it, the AIR value shows you how many remote AI is alive.

But AI local on other clients is included here too, so it could make sense to monitor the HC additional.

If your HC is heavy loaded (COOP mission, 300+), some other values could be interesting too.

So, if you need more detailed data from your HC instance, you could sign @ASM by yourself.

That should have no disadvantages, because the @ASM mini-addon is not shared with your clients (except the HC)

and is just meaned as simple way to start the fn_ASM.fsm.

Greets,

Fred41

Hello.

Awsome tool you got there, using it alot :) Thx for your work mate.

Now, am i overlooking something? I cant seem to find a key for the .pbo, to use on my server. Im running with sig verify, so my HC (when loading with ASM) gets kicked.

Would you be able to sign the addon mate? Or am i simply overlooking the key somewhere hehe?

I want to monitor both the server and HC but atm it doesnt seem possible with sig verification turned on :)

Hope you can "fix" it, or point me in the right direction, if im missing it somewhere :)

Edited by Fred41

Share this post


Link to post
Share on other sites

Ok thx for your answers guys :)

I did think about the AIR monitor like you said, but the reason i asked was for pure testing purposes, simply to gather as much information as possible.

Will proberly sign it my self then hehe, just wanted to know if it was planned anywhere down the road (gonna take that as a no :) )

Keep up the good work mate, this tool is a must have for server admins and mission testers/builders tbh.

Share this post


Link to post
Share on other sites

Thanks for hosting the files on github, however the source is not there =(

I see great potential in this tool and a good foundation has been made, however I wish it could output it some way so I can store it in an RRD or similar for generating graphs to put on a webpage. For debugging purposes of missions the existing implementation is complete, I want a bit more though (-:

Thoughts? I only need to know how I can get the data, tried a wireshark trace, didn't get quite much from that in regards to the packet/data structure (I'm a noob, I know).

The documentation is a bit unclear if you still need to edit maps for this to work, from what I've tested with, you don't as long as the mod is loaded on the server, is this correct?

Share this post


Link to post
Share on other sites

FlyingCorpse, thanks for your reply.

This tool is made for A3, here you just have to use the @ASM mod as documented.

(For use in A2, you have to load the fn_ASM.fsm in your init.sqf mission file, for each mission you wish to monitor.)

Do you plan to make your web-interface for public?

If yes, i could support you, because i planned this too, but didn't found the time so far.

The data structure and the remote protocol are intentionally very simple to allow high performance.

There are basically, two ways to access the data:

  • direct, via shared memory read
  • indirect via ArmaServerMonitor in server mode, using a simple TCP protocol

For shared memory access, the FileMappings are called ether 'ASM_MapFile' or 'Global\ASM_MapFile' for use with admin rights.

There is on page (4096 Bytes) for each server instance. The datastructure is as follows:

#define SMALSTRINGSIZE 32
struct ARMA_SERVER_INFO 
{
    DWORD	PID;
    DWORD	OBJ_COUNT;
    DWORD	MEM;
    DWORD	PLAYER_COUNT;
    DWORD 	AI_COUNT;
    DWORD 	AI_REM_COUNT;
    DWORD	SERVER_FPS;
    DWORD	SERVER_FPSMIN;
    DWORD	FSM_CE_FREQ;
    char	MISSION[sMALSTRINGSIZE];
    char	PROFILE[sMALSTRINGSIZE];
};

The ArmaServerMonitor TCP protocol is simplest (pascal code):

procedure TForm1.ServerSocketClientRead(Sender: TObject;Socket: TCustomWinSocket);
var i: integer;
   req: cardinal;
begin
 Socket.ReceiveBuf(req, sizeOf(req));
 case req of
   0: begin
        for i := 0 to MAX_ARMA_INSTANCES - 1 do begin
            Move(ASI[i]^.PID, ASMRemote[i].PID, SizeOf(TASMInfo));
        end;
        Socket.SendBuf(ASMRemote, sizeOf(ASMRemote));
      end;
 end;
end;

Where ASI and ASMRemote are of type TASMInfo (which is identical with struct ARMA_SERVER_INFO from above). 

This means your TCP client just have to send a DWORD 0. The server will reply with one TCP packet containing the whole current data for all 4 instances.

Thanks for hosting the files on github, however the source is not there =(

I see great potential in this tool and a good foundation has been made, however I wish it could output it some way so I can store it in an RRD or similar for generating graphs to put on a webpage. For debugging purposes of missions the existing implementation is complete, I want a bit more though (-:

Thoughts? I only need to know how I can get the data, tried a wireshark trace, didn't get quite much from that in regards to the packet/data structure (I'm a noob, I know).

The documentation is a bit unclear if you still need to edit maps for this to work, from what I've tested with, you don't as long as the mod is loaded on the server, is this correct?

Edited by Fred41

Share this post


Link to post
Share on other sites

The "web interface" will probably be very simple, written in either perl or python as I want to stay platform independent hoping ArmA III server in the future supports Linux ;)

What I'd probably be able to write is a simple tool that can open a connection, query and take the recieved data and store it to an RRD file. it can then also generate a graph based on this every X seconds (custom location) so it can be put on a webpage.

Should not be too hard, albeit I'm stuck with the UDP connection/socket handling so far.

Edit: NVM on the UDP, ASM doesn't listen on UDP.

Edited by TheFlyingCorpse

Share this post


Link to post
Share on other sites

+1 gets my vote to get a web interface able to see the feed from the server monitor. then I can have a glance from my Ipad whenever I feel like it. Hope it works out.

Share this post


Link to post
Share on other sites
... ups, sorry meant TCP (previous post edited) ...

Might there be an option where you can dump the data recieved into a folder specified by argument, example:

- Dump the data obtained every 10s (just that sample from that 10th second) (argument for how often) to a flat file with a name like profile.<epoch> or similar, inside it you dump each type on a new line, eg: FPS=VALUE

This way, the process to fetch and process the data is no longer on the gaming server if the parser is connecting remotely. This way, you can also change it as you please in the future, adding and removing the data types without worrying of screwing up the interface for the parser. Then its quite simple for anyone to take use of the data as well, being it RRD (for those of us who prefer that) or something else.

The issue I see is that its not that easy to find a unique key to identify the instances, other than profile name, here being "default" in most instances. With several servers running on the same monitor, this might be an issue if they all run with "their" default. I have no way of separating them then to separate stores, unless the ASM stores each instance in its own folder with some internal logic to identify each.

Thoughts?

Share this post


Link to post
Share on other sites

... why not simple remote fetching the data periodical via TCP socket?

This way you are most flexible and receives the same data as ArmaServerMonitor does. And you can process the data as you prefer (displaying, storing, comparing).

Also, you dont need a ArmaServerMonitor -client anymore in this case.

Unique key for instance identification is still the profile name, you just have to set it unique for each instance (-name=NameOfInstanceX).

Might there be an option where you can dump the data recieved into a folder specified by argument, example:

- Dump the data obtained every 10s (just that sample from that 10th second) (argument for how often) to a flat file with a name like profile.<epoch> or similar, inside it you dump each type on a new line, eg: FPS=VALUE

This way, the process to fetch and process the data is no longer on the gaming server if the parser is connecting remotely. This way, you can also change it as you please in the future, adding and removing the data types without worrying of screwing up the interface for the parser. Then its quite simple for anyone to take use of the data as well, being it RRD (for those of us who prefer that) or something else.

The issue I see is that its not that easy to find a unique key to identify the instances, other than profile name, here being "default" in most instances. With several servers running on the same monitor, this might be an issue if they all run with "their" default. I have no way of separating them then to separate stores, unless the ASM stores each instance in its own folder with some internal logic to identify each.

Thoughts?

Share this post


Link to post
Share on other sites

http://forums.bistudio.com/showthread.php?149412-Arma-3-Headless-Client&p=2515839&viewfull=1#post2515839

I went ahead, pulled together the different sources on DAC from this board (no credit to me on that end) and made a simple ArmA 3 Headless Client test.

The HC feature is parameterized, enable this before loading the map as admin to notice a great difference in performance. Note you will lag in the end, this mission runs up to 1000+ AI when both sides are spawned. Step close to the boat to get the baddies to spawn.

Demo map: http://www.mediafire.com/download/mhjsycsg21yr9fj/a3_hc_test.Stratis.pbo

1st half is without HC on the graph below. The 2nd half is with HC. Its 500 AI the max+ (the graph caps out around 450 AI spawned)

NtruTOC.png

Share this post


Link to post
Share on other sites

... hmm, seems i have to rescale AIL & AIR ...

UPDATE:

AIR & AIL history graph scaled from 400 max. to 800 max

Share this post


Link to post
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now

×