Some users do not appear in map

[jonjamcam]

[elieserdejesus]

@jonjamcam , this can be related with refresh time in JamTaba.

Maybe the ninjamer Piw enter in the server but JamTaba is not updated yet? You waited some seconds ?

ps: I'm just trying to eliminate the simple hyphothesys, maybe this is not a bug.

[jonjamcam]

Maybe the ninjamer Piw enter in the server but JamTaba is not updated yet? You waited some seconds ?

Unfortunately it's not the case @elieserdejesus . Just checked again:

I'm documenting just to be sure. ATM I don't have any idea why it happens.

[jonjamcam]

I have an hypothesis @elieserdejesus . It looks to me there's a problem related to the cache. Jamtaba is not updating cache for new users, so only "known" users are shown. Maybe there's a problem with ipapi?

EDIT: If local cache folder is empty, no users are shown. Is it only me?

[elieserdejesus]

I checked ipapi dashboard and the free monthly quota is expired:

Too mutch requests, maybe the cache is not working as expected:

[elieserdejesus]

Idea: Use more than one IP to Location APIs. When one API free plan is exausted (returning some error code) the other API is used.

https://ahmadawais.com/best-api-geolocating-an-ip-address/

[elieserdejesus]

Another idea: ipapi allow to look up multiple IP addresses at once, reducing the requests.

[elieserdejesus]

Just to documenting: The json returned by ipapi when API limits is exausted:

{
  "success": false,
  "error": {
    "code": 104,
    "type": "usage_limit_reached",
    "info": "Your monthly usage limit has been reached. Please upgrade your Subscription Plan."
  }
}

[jonjamcam]

So Jamtaba is using 1000 to 1500 requests a day on weekends and probably this number will continue to grow in the future.

Is there a way for each client to obtain this geolocation information from a centralized database, so the requests to ipapi.com are one per user connected, not one per client as it is now?

[elieserdejesus]

So Jamtaba is using 1000 to 1500 requests a day on weekends and probably this number will continue to grow in the future.

Yes, this number is too high. Is like people are deleting the cache files many times while jamming. This make no sense 😄 .

---

Is there a way for each client to obtain this geolocation information from a centralized database, so the requests to ipapi.com are one per user connected, not one per client as it is now?

Is possible change the cache to be stored in JamTaba server, not in each client, so the cache is centralized. And maybe the Google App Engine (running JamTaba Server) has some built in Ip to location service. I will check!

[elieserdejesus]

maybe the Google App Engine (running JamTaba Server) has some built in Ip to location service

I checked, no built-in Ip to Location in Google App Engine.

I'm using an third part IP To Location database in JamTaba Server, but is not possible translate the country name.

---

I think the best possibilities at moment are: 1 - Use the bulk ip to Locaiton (translate all connected ninjamers IP to Country in one pass). This will reduce the requests to ipapi (other APIs are supporting the same approach).

2 - Use a second free API as fallback.

[fab672000]

I think Eli suggestion is nice (fallback to another free api) but I just got another idea more for developers like us: how about having an optional personal key. It is easy to implement as all we need to do is to provide a code that checks for this custom code if it exists in WebIpToLocationResolver::requestDataFromWebService(const QString &ip)

Just got another idea: How about masking the last 8bits of the ip address before caching: that way you potentially significantly improve the cache hits as now potentially 250+ users sharing the same isp can be cached ? i.e.: suppose my address is 44.45.46.234, you mask (logical and of 0xffffff00) the last byte now you get 44.45.46.0 to store (or simply 44.45.46). now if my neighbour uses 44.45.46.210 it also matches and you get the same country code and name in the caches.

We could probably extend the idea to subnet masks allowing more computers than 255, like 255.255.0.0 subnet masks ?

Thoughts?

[fab672000]

Was thinking of a new preferences tab, like:

[elieserdejesus]

Just got another idea: How about masking the last 8bits of the ip address before caching: that way you potentially significantly improve the cache hits as now potentially 250+ users sharing the same isp can be cached ?

I'm not 100% shure (I can't remember at moment), but I think we are using a similar idea. Ninjam IPs are masked, so we never see the complete IPs adresses.

---

About the new preferences Tab:

I'm from the "ridiculous easy to use" team 😄 . My main rule in this topic is: if just a couple of users (devs and geeks) will use the feature is better put the parameters in a config file, not in the UI.

[jonjamcam]

Hey @fab672000 and @elieserdejesus . So the problem we have here is getting a number of parameters so the map works correctly. Of course this information is available at any moment locally in each client. Taking fab's idea and expanding it let's imagine each jamtaba client creates a unique key automatically when logged to jamtaba server, sends it and the server can "decrypt" it and use it.

With this approach, each client will only ask for this data once (it can be cached locally) or as much as the local isp changes the data reducing to a fraction the number of hits. A combination of centralised cache and fab's override key.

I like fab's idea, but I agree with eli it's too complex for the typical user to type in manually.

[fab672000]

I'm from the "ridiculous easy to use" team 😄 . My main rule in this topic is: if just a couple of users (devs and geeks) will use the feature is better put the parameters in a config file, not in the UI.

Fair enough, as you probably guessed I have a piece of code that could do that fairly easily ATM, i just need to remove my early prototyping ui code of yesterday night and keep only the config aspect as discussed. I'll see what I can do this WE on that too ...

Taking fab's idea and expanding it let's imagine each jamtaba client creates a unique key automatically when logged to jamtaba server, sends it and the server can "decrypt" it and use it.

With this approach, each client will only ask for this data once (it can be cached locally) or as much as the local isp changes the data reducing to a fraction the number of hits. A combination of centralised cache and fab's override key.

That sounds interesting, but I don't see yet how we would get a unique key per client as the only key I know of ATM is your unique registered user API key. Are you saying that we could create as many keys as we would like with an API key auto-registration mechanism ? Or am I confusing API key with another key mechanism you would suggest ?

[fab672000]

I also still like meanwhile the simple backup alternative ip mapping server approach proposed by @elieserdejesus here and may be able to give it a try this WE

[jonjamcam]

Are you saying that we could create as many key as we would like with an autoregistration mechanism ? Or am I confusing API key with another key mechanism you would suggest ?

Sorry for the confusion @fab672000 . I'm using the word "key" here to describe a unique string that contains all the data needed as in "encrypted key". I thought this could be more efficient when transmitting data.

[fab672000]

OK, so I could use a potentially nice alternative to ipapi named ipinfo.io, the only thing is that the full name is not returned by the request but everything else could be used (including lat/long). I'd like to implement it and use a default country fullname from a default json dictionary or from http://country.io/names.json.

The idea being that if we don't find the country in the current language dependent country cache, we fall back to the default (en) map. Would it be acceptable?

This could be useful as it would open the door to many more alternatives, by having minimum requirements.

Thoughts?

[fab672000]

Also, we already have a flag png resources folder, why not having a default (country_code,country_name) map and avoid to depend too much on these servers ?

We could have our usual translators translate these in different languages, now we would have an international fallback mechanism?

The country codes are quite stable, I'm thinking keeping them up-to-date should be easy?

[fab672000]

Meanwhile api.ipstack.com has everything we would need today with minimum modifications, so maybe I'll try this first

[fab672000]

Have apistack alternative server working on my branch ! Another 10000 calls per months backup!

[jonjamcam]

Sounds like a great solution!

Just checked your branch. Working perfect in windows! Great work!

[fab672000]

thanks reserved another key dedicated exclusively for jamtaba new PR coming ready to use!! :) That was eli's great idea btw i just implemented it ;-)

[elieserdejesus]

Have apistack alternative server working on my branch ! Another 10000 calls per months backup!

Nice @fab672000 , thanks!