Sanderling memory reader down

Just thought I would point out the site is returning an exception for the memory reading function.

Thank you!

Just thought I would point out the site is returning an exception for the memory reading function.

Thank you!

Yes, the ISP hosting this server writes there was a connectivity problem for 55 minutes ending at 18:06 CET.

If you are seriously considering making use of the bot a paid service, then as a potential customer I would like to put in a feature request.  Please architect the pay-for-use product such that I do not lose bot use everytime the bot forum goes down for whatever reason.  As a user I am willing to tollerate the following behaviors:

  1. If the bot site is down I cannot start a new bot session.

  2. If my bot client is running I expect it to remain running even if the bot site is down.

  3. If the bot site is down for over a 24 hour period (i.e. the bot client has not been able to validate my bot license) then I can accept a termination of an active bot client if my ship is safely returned to dock.

I have enjoyed using this application for the last few months and would like to continue in the future if it becomes a paid service.

Hack.

If you are seriously considering making use of the bot a paid service, then as a potential customer I would like to put in a feature request.  Please architect the pay-for-use product such that I do not lose bot use everytime the bot forum goes down for whatever reason.  As a user I am willing to tollerate the following behaviors:

  1. If the bot site is down I cannot start a new bot session.

  2. If my bot client is running I expect it to remain running even if the bot site is down.

  3. If the bot site is down for over a 24 hour period (i.e. the bot client has not been able to validate my bot license) then I can accept a termination of an active bot client if my ship is safely returned to dock.

I have enjoyed using this application for the last few months and would like to continue in the future if it becomes a paid service.

Hack.

Ok, I can built it so that you can continue to use it for some time after disconnection. I do not see how 24 hours would work though as there are conflicting requirements.

I figured you would want to let a bot run for no longer than 24 hours without validating the runtime license.  If I assume you will periodically validate the licence during normal operations, then a loss in license server should start a timer in the bot that will cause it to shutdown after a period of time it is out of contact.

In these types of license systems you typically see and interaction something like the following:

  1. Client requests a runtime license from the server using a key.

  2. Server validates the client key.

  3. Server issues a temporary license with an expiry date.

  4. Client uses license to access functionality.

  5. Client renews license before expiry date.

On startup the client must use key to obtain license.  The server can reject client request if key is invalid.

How long the temporary license is valid is up to you.  The interesting thing is you can extended the expiry date of issued licenses on the server-side if you are expecting a longer maintainence window.

Hack.

I figured you would want to let a bot run for no longer than 24 hours without validating the runtime license.  If I assume you will periodically validate the licence during normal operations, then a loss in license server should start a timer in the bot that will cause it to shutdown after a period of time it is out of contact.

In these types of license systems you typically see and interaction something like the following:

  1. Client requests a runtime license from the server using a key.

  2. Server validates the client key.

  3. Server issues a temporary license with an expiry date.

  4. Client uses license to access functionality.

  5. Client renews license before expiry date.

On startup the client must use key to obtain license.  The server can reject client request if key is invalid.

Ok, so far I see no problem. I think I can make it work this way.

How long the temporary license is valid is up to you.  The interesting thing is you can extended the expiry date of issued licenses on the server-side if you are expecting a longer maintainence window.

Hack.

Yes, I can extend the expiry date of the license while it is in use.

The validity duration of the temporary license is constrained because I might want to prevent people from using one license for multiple eve online clients at the same time.

The validity duration of the temporary license is constrained because I might want to prevent people from using one license for multiple eve online clients at the same time.

Hmmm… this is an interesting one.  We would usually restrict licenses based on physical system attributes like MAC address or CPU serial numbers.  In your case a person may be running multiple clients on a single machine, or as is my case, I have 5 different machines I may run the client from depending on which room I am playing in (or more specifically, where the kids are not!).

Have you thought about the mechanism you will use to enforce these licenses?  Are you thinking about delivering a purchased license key that they enter into the client, or were you thinking the enter credentials into the bot client that accesses their account on bot forums for license lookup?

Have you thought about the mechanism you will use to enforce these licenses?  Are you thinking about delivering a purchased license key that they enter into the client, or were you thinking the enter credentials into the bot client that accesses their account on bot forums for license lookup?

The current plan is that the user will receive one key per license and sends this key to the server when starting a session. (In the  the sample bot executable, the key can be entered in the UI)

Okay, so a strightforward mechainsm where a session license is created using the provisioned key and a unique identifier (timestamp, process id) which gets digitally signed on the server side to create the license.

Server detects the same key is being used by a different client session it expires the previously generated license and creates a new one.  If a client tries to use the old expired license is gets rejected and the session is invalidated.

I can see now why 24 hours of not accessing the server could cause problems.  On client #1 I use the key to get a valid session then use my firewall to block the bot from communicating with the server.  On client #2 I use the same key to get a new license.  The server expires the old license but client #1 does not come back to find out its license has been invalidated.  For a 24 hour window I can run two clients.

You will definitely want to keep the normal license check/refresh very short (an hour or less) to avoid someome trying to bypass the licensing check.  An hour would let the client survive small outages, and for bigger planned ones you can increase the license duration temporarily.

Hack.

1 Like