| Pages: [1] :: one page |
| Author |
Thread Statistics | Show CCP posts - 0 post(s) |

Tiberius Xavier
Eternity INC. Mercenary Coalition
|
Posted - 2008.03.22 16:26:00 -
[1]
EVEPOSTimer v1.0.0.0
I created a little application to facilitate POS tracking in large campaigns. Perhaps you have seen the output of this tool in other threads. In any case, I was wondering who would be interested in being testers of this latest version. The following sections is a rough draft manual. Feel free to ask questions of course.
Brief Description This little application is intended to track the friendly, neutral and hostile POSes in various systems and automatically generate a report in either plain text or using BBCode (which can be customized). It is capable of aiding the calculation of Reinforce Times as well.
Screenshot: Main Window
Sync Window
Options Window
Collaborators Window
Standings Window
Report Builder Window
About Window
Quick Op Report
Installation Use the packaged installer .msi script: EVEPOSTimer.msi.
By configuring Your Signature in the options, you automatically apply your credentials to any changes on the data. Moreover, you can define a collaborators list (see section below) to facilitate the Synchronization feature.
Report Generation Currently there are two generation options available. The first is plain text, which allows an easily readible report. The second is a BBCode generation which can be pasted into a vBulletin post. The second format can be overriden so that the BBCode tags are customizeable.
Custom report generation is also possible with interactive checkboxes. The settings used for the generation are retained for the next generation whether done through custom or the direct text or BBCode generation.
Merge External XML files can be merged into the working copy of the XML file. It is based on the lastest timestamp of updated data after filtering by options allow 3rd party (unlisted collaborators) and unsigned (anonymous) entries. Merging directly uses a write level of 10 which effectively allows universal write permissions.
Synchronization By default options, the application enables itself as a server on TCP port 8825. In your data file, you can designate a list of collaborators which consists of a player name, corp, alliance, network address, TCP port, Is Server (client/server or client only), read level, write level and password. For example, I am "Tiberius Xavier", "ETNY", "MC", "127.0.0.1", "8825", Is Server CHECKED and ideally read/write level of 10 and 10. If I add your information to the collaborators list, then you can connect to me and we can exchange information (you can optionally merge with my latest). If you expose a server port, then I can upload data to you as well. The synchronization process is always initated manually and only one side need a server port (although both is acceptable).
|

Tiberius Xavier
Eternity INC. Mercenary Coalition
|
Posted - 2008.03.22 16:27:00 -
[2]
Edited by: Tiberius Xavier on 22/03/2008 16:32:59 Synchronization Options Under the options section, there are several options available for controlling the behavior of the merge process. They are:
- Enable Server - This enables the server end to accept inbound connections on the TCP port. If it is not checked, all incoming connections will be rejected. Make sure peers designate you as a client only to avoid unnecessary synchronization attempts.
- Merge On Remote Synch Requests - This enables the merging of data received from inbound peer connections. If this option is not enabled, then all data sent by the peer is ignored (only useful for sending information).
- Merge On Local Synch Requests - This enables the merging of data received from outbound peer connectinos. If this option is not enabled, then all data sent by the peer is ignored (only useful for sending information).
- Merge 3rd Party Entries - This enables the content signed by non-collaborators to be included in the merge process.
- Merge Unsigned Entries - This enables the content not signed by anyone to be included in the merge process.
- Synchronize Periodically - This option allows the application to periodically initiate a synchronization process.
- Synchronize At Startup - This option allows the application to initiate a synchronization process at startup.
- Auto-Reject Non-Collaborators - This option allows the server to reject non-collaborators attempting to connect to the server. If this option is not enabled, then a prompt to accept/reject will be provided.
- Authenticate Inbound Peers - This option validates that the remote IP address of the peer matches the entry in the collaborators list. This is useful as a weak authentication of the inbound connection. This feature can only function if all collaborators are on static IP addresses.
Read/Write Level Permissions
When dealing with synchronization, there are four global numbers that are involved:
- Client Read Level
- Client Write Level
- Server Read Level
- Server Write Level
Consider the following examples: R0ot (client) and Tiberius Xavier (server)
R0ot has Tiberius Xavier defined with Read Rights 9 and Write Rights 6. Tiberius Xavier has R0ot defined with Read Rights 8 and Write Rights 7.
Before Sync:
- Root has:
- Entry 1 has Security Level 5
- Entry 2 has Security Level 6
- Entry 3 has Security Level 7
- Entry 4 has Security Level 8
- Entry 5 has Security Level 9
- Entry 6 has Security Level 10
- Entry 10 has Security Level 8
- Tiberius Xavier has:
- Entry 7 has Security Level 5
- Entry 8 has Security Level 6
- Entry 9 has Security Level 7
- Entry 10 has Security Level 8
- Entry 11 has Security Level 9
- Entry 12 has Security Level 10
Action for when R0ot sends:
- Sent and Accepted: Entry 1 has Security Level 5 [COLOR=green](sufficient write permissions)[/color]
- Sent and Accepted: Entry 2 has Security Level 6 [COLOR=green](sufficient write permissions)[/color]
- Sent and Accepted: Entry 3 has Security Level 7 [COLOR=green](sufficient write permissions)[/color]
- Sent and Accepted: Entry 4 has Security Level 8 [COLOR=green](although write permissions are not enought to update, new entries are allowed to be created)[/color]
- Sent and Accepted: Entry 5 has Security Level 9 [COLOR=green](although write permissions are not enought to update, new entries are allowed to be created)[/color]
- Not Sent: Entry 6 has Security Level 10 [COLOR=red](not enough read permissions to send)[/color]
- Sent amd Rejected: Entry 10 has Security Level 8 [COLOR=red](not enough write permissions to overwrite)[/color]
|

Tiberius Xavier
Eternity INC. Mercenary Coalition
|
Posted - 2008.03.22 16:34:00 -
[3]
Action for when Tiberius Xavier sends:
- Sent and Accepted: Entry 1 has Security Level 5 [COLOR=green](sufficient write permissions)[/color]
- Sent and Accepted: Entry 2 has Security Level 6 [COLOR=green](sufficient write permissions)[/color]
- Sent and Rejected: Entry 3 has Security Level 7 [COLOR=red](not enough write permissions to overwrite)[/color]
- Sent and Rejected: Entry 4 has Security Level 8 [COLOR=red](not enough write permissions to overwrite)[/color]
- Not Sent: Entry 5 has Security Level 9 [COLOR=red](not enough read permissions to send)[/color]
- Sent and Accepted: Entry 7 has Security Level 5 [COLOR=green](sufficient write permissions)[/color]
- Sent and Accepted: Entry 8 has Security Level 6 [COLOR=green](sufficient write permissions)[/color]
- Sent and Rejected: Entry 9 has Security Level 7 [COLOR=red](not enough write permissions to overwrite)[/color]
- Sent and Rejected: Entry 10 has Security Level 8 [COLOR=red](not enough write permissions to overwrite)[/color]
- Not Sent: Entry 11 has Security Level 9 [COLOR=red](not enough read permissions to send)[/color]
- Not Sent: Entry 12 has Security Level 10 [COLOR=red](not enough read permissions to send)[/color]
After Sync:
- Root has:
- Entry 1 has Security Level 5
- Entry 2 has Security Level 6
- Entry 3 has Security Level 7
- Entry 4 has Security Level 8
- Entry 5 has Security Level 9
- Entry 6 has Security Level 10
- Entry 7 has Security Level 5
- Entry 8 has Security Level 6
- Tiberius Xavier has:
- Entry 1 has Security Level 5
- Entry 2 has Security Level 6
- Entry 3 has Security Level 7
- Entry 4 has Security Level 8
- Entry 5 has Security Level 9
- Entry 6 has Security Level 10
- Entry 7 has Security Level 5
- Entry 8 has Security Level 6
- Entry 9 has Security Level 7
- Entry 10 has Security Level 8
- Entry 11 has Security Level 9
- Entry 12 has Security Level 10
|

Tiberius Xavier
Eternity INC. Mercenary Coalition
|
Posted - 2008.03.22 16:34:00 -
[4]
Synchronization Process Explained
The synchronization process involves a peer to peer connection with each collaborator listed as a server. If any error occurs during the synchronization process, the attempt is aborted an the error message is logged and also sent to the client. The steps are:
- Upon establishing a connection, the inbound IP addressed is validated as a known collaborator (if the option is enabled on the server).
- The client then initiates the data exchange by sending the client (sender) signature and collaborator (receiver) signature, all POS entries up to (inclusive) read level designated by the client for the server collaborator.
- The server will then validate that the client siganture is listed in the collaborators list and that the password matches.
- All POS entires up to (inclusive) the write level designated by the server for the client collaborator are extracted from the inbound set.
- All unknown (3rd party) entries (collaborators unknown to the server) is pruned from the set (if the option is enabled on the server)
- All unsigned (anonymous) entries is pruned from the set (if the option is enabled on the server)
- The result set is merged into the server after a backup is created (if the option is enabled on the server)
- The server replies ith a list of entries up to (inclusive) read level designated by the server for the client collaborator.
- All POS entires up to (inclusive) the write level designated by the client for the server collaborator are extracted from the inbound set.
- All unknown (3rd party) entries (collaborators unknown to the client) is pruned from the set (if the option is enabled on the client)
- All unsigned (anonymous) entries is pruned from the set (if the option is enabled on the client)
- The result set is merged into the client after a backup is created (if the option is enabled on the client)
Guest Access
Suppose we temporarily go blue with someone. We can make sure all our own POSes are at securiy level 10 and that hostile POSes are at say level 5. We can then set ForeignAllianceLeaderNameHere to Read Rights 5 and Write Rights 1. They can access our intel on hostile POSes but not friendly POSes. Then can create new entries but not update any existing entries. If they are set to 5/5, then they can (in this case) get the hostile POSes and update the hostile POSes, but the friendly POSes remain unknown and secure from overwriting.
|

Carniflex
Fallout Research Fallout Project
|
Posted - 2008.03.23 08:12:00 -
[5]
Interesting application. I did not notice tho if it was supporting advanced API pos tracking features also (I think it's broken after last patch anyway) ?
A bit overkill for small scale operations ofc but nice work nevertheless :) I was asking about that advanced API stuff bcos it's one of the first POS applications where I see proper security protocols implemented as giving out your adv API would give out a lot of information, while with this app (if it supports API) it might be possible to run it as 'filter' between your API and your allies giving out only that kind of information they need (say your POS locations and status) and does not give out sensitive information (like your corp members list, their locations and corp assets list) and all that without having to actually give out your API key.
|

Tiberius Xavier
Eternity INC. Mercenary Coalition
|
Posted - 2008.03.23 14:19:00 -
[6]
Thanks. This application does not use the API at all. There are ideas and plans to incorporate the API in order to keep the corporations list fresh, to include the area soverignty information and to include rapid data entry of corp owned POSes.
The real value of this tool comes at large scale or multiple theater POS warfare. The primary goal was to keep track of which towers (both friendly and hostile) are exiting reinforced mode. When multiple scouts collaborate, then the 'big picture' gets more impressive.
|

Skelator0311
STK Scientific Black-Out
|
Posted - 2008.03.25 18:34:00 -
[7]
WOW this is very well put together! It will take some playing with to figure it all out. I would love this even more if it had some sort of API interaction so as to automate the towers that belong to you.
|

Pwett
QUANT Corp. QUANT Hegemony
|
Posted - 2008.03.25 20:44:00 -
[8]
Fantastic, it puts my programming skills to shame! _______________ Pwett CEO, Founder, & Executor <Q> QUANT Hegemony
|

Tiberius Xavier
Eternity INC. Project Alice.
|
Posted - 2008.05.25 20:04:00 -
[9]
Edited by: Tiberius Xavier on 25/05/2008 20:05:00 Updated the tool to version 1.1.0.0
Added the following changes (by popular demand):
- Download Alliance/Corp lists via API (keyless)
- Download system sovereignty information via API (keyless)
- Update owned POSes (director via API full/secure key)
- Added sovereignty in the report generation and on the sidebar editor (read only)
|

Alex Redwidth
|
Posted - 2008.05.25 21:46:00 -
[10]
Goodbye endless scraps of paper around the office.
Thanks for fufilling a need I didn't know I had.
|

NoNah
Tenth Legion Holdings Tenth Legion
|
Posted - 2008.05.26 10:48:00 -
[11]
Obviously my paranoia, and it's most likely explained somewhere in the posts that I missed, but...
Wouldn't this mean that every single client feeds you with info about info on their poses, fuel levels, timers etc etc?
Basically giving you a huge database, from which you can pretty much extract any info you might enjoy at your convieniance?
Any chance of getting a oogle on the source for it, just flipping the switch making it open source?
Postcount: 745350
|

Tiberius Xavier
Eternity INC. Project Alice.
|
Posted - 2008.05.26 14:50:00 -
[12]
Originally by: NoNah Obviously my paranoia, and it's most likely explained somewhere in the posts that I missed, but...
Wouldn't this mean that every single client feeds you with info about info on their poses, fuel levels, timers etc etc?
Basically giving you a huge database, from which you can pretty much extract any info you might enjoy at your convieniance?
Any chance of getting a oogle on the source for it, just flipping the switch making it open source?
Those are good questions not answered explicitly.
Fuel levels are not being tracked by this tool, only location, type, size, owner, basic status (online,anchored,destroyed,reinforced), exits reinforced time, sovereignty and notes entered. All this information has a security level associated to it. Only contents up to that security level is shared to a collaborator, and only contents up to that level will be accepted from a collaborator to be included on your side.
In the logging, you have an option for creating xml files for the contents that is actually serialized out to, and deserialized in from, the collaborator. Running a server is also optional. Theoretically, you can do all the scouting yourself without a server and generate reports accordingly. Logs are taken of all access to the server as well.
As for the API portion, entering in a director's full API key is optional. That allows your corp owned POSes to be entered quickly, but of crouse a manual approach works without that. The alliance list and sovereignty information is accessible from CCP without a key. So that information can be kept up to date anytime you feel like it.
The icons and images I use are not freeware, so I cannot make that available. I can share the client/server portion, but I don't want to provide hackers (sadly they are out there) knowledge of how infiltrate a server. However, I'll share the client end.
|
| |
|
| Pages: [1] :: one page |
| First page | Previous page | Next page | Last page |