[PaulDinam]

Why does SAMP Query socket only allows up to 100 players? It's also restricted on the samp client itself but when using PHP sockets as well, which is annoying. I'm creating an API for a server which has over 400 players daily.

[Paulice]

Because I guess it would be a waste of resources and may create delay when there are a lot of requests.

What you can do is return the data with sockets or HTTP.

[Kaperstone]

Stress.
It will take more bandwidth, processing and time to process it, essentially freezing your entire server until it sends all the players in the server in a response to a query.
Imagine sending a Russian playerlist.

You can track over 100 players by storing the players in a database, file or sending a socket to another interface and it do the work.

I personally, wouldn't even want that feature to be in there, to begin with.
The query feature is already a pretty weak feature which can easily break by flooding it, I wouldn't want to put stress on it ontop of sending the basic server information.

I'd rather create a list of online players on a website or a modified client that queries an async backend than this.

EDIT: by calculating the length of it, lets assume everything is maximized
24 name char, 5 char score, 5 char ping
34 * 100 = 3400 char
34 * 400 = 13600 char
34 * 1000 = 34000 char
(this doesn't take into account any extra's that come with on each socket)
this entire thread as of now is 66600, so it means on a populated server it would take quarter of this page to send - sync, on a single query.

[jamesbond007]

idk i always wondered that.. it seems broken

[jlalt]

You can simple insert players inside a mysql table and load by php. [ best way so far as it won't bother the server and samp mysql's threaded. ]

or as said above the server calls a php api every now and then and updates the stuff for the php page.
ex an request for when player join with his information and another request when player dis.
[ also will need to reset players list at ongamemodeinit. ]

sending all players information at once will be pain in @$$ a bit, lets imagine you got 400 players, 26 char for every name, 400 * 26 = 10,400, so now you got 10kb to be sent on every list me players request.

[ here is it when d(d)os attacks become more effective ]

[azzerking]

Quote:

Originally Posted by [HLF]Southclaw One of the things I wanted to solve via the listing service I built - however I haven't tested it yet! It works on the inverse though, instead of some API consumer wanting to request a particular server and putting stress on that server, the server itself posts its player list every now and then to the service which API consumers request for the list. Though, right now no server is POSTing their player list to the service because I haven't built a plugin to do it yet! But when I do, it will collate and post the entire player list in a separate thread. But the main question here - before even fully putting that feature live - is, who cares? Who really needs to know every single player name on every server? Not a leading question at all! I genuinely want to know a use-case here.

I would be careful with that one, your service would be pretty useless if someone decided to constantly send playerlist data to your API therefore overloading your server and delaying replies.

Unless you have setup some advanced packet sniffing to sort out request attacks or you have a firewall to block request sent from a server before a set-timeout, I wouldn't go ahead with it.

Yes you could block the servers IP, but then again we come back to DDOS, or packet manipulation attacks.

I would have a 2 backup servers just in-case one goes down, else your masterlist is useless. I feel the only reason sa-mp's masterlist hasn't been attacked (or maybe has in past) is because the people ddos-ing probably own a server and wouldn't want to see it down.

As for you, your list is second to sa-mp's and therefore more of a target for trolls.

[jlalt]

Quote:

Originally Posted by [HLF]Southclaw That's why the final statement is important - if there are no use-cases for this then there's no point going through the ordeal required to set it up as a feature. I'm aware of the dangers already which is why the feature is not live right now! I'm just hoping to extract any possible use-cases from people whenever possible. That's why I'll probably just build a plugin to do this so developers can query their own server for their own data and deal with firewalling it themselves. Two ways I'd handle it: - Write a super simple plugin that runs a HTTP server that serves a player list on some endpoint /v1/players for example - Set up my web backend to query/cache that result and render it to my web frontend - no public access to /v1/players Or - Store player list in a Redis set or list via the Redis plugin - Set up my web backend to simply read that Redis set and render it to the web frontend

Very nice, I also would suggest to let the request encode the data with the key as the same ip which's sending the request. [ ex if my server ip 127.0.0.1 it gotta encode the data by 127.0.0.1 key which for sure should be my OWN ip [ or also comparing the server ip and requester ip ] ] that way you would be sure there's no fake requests being sent to you and ruining your list.

Good luck with this project!