This URL http://www.lfsworld.net/pubsta ... sion=1.1&action=hosts
sends all oldS1, newS1 and S2 Hosts. But how can i get a List of Demo hosts?

And how can i tell the LfS.exe to connect directly to a demo-server?
If my LfS is set to Demo or S1 and I start it with a S2-server I get the Message "wrong Version"

Is there another parameter für lfs.exe?

Thanx

Weird.. when I click on that link, or paste it into the address bar it asks me to save the .php file? Of course, its not the code but a bunch of weird characters and scattered text.. Might have something to do with mime types.. Using Firefox btw.

As far as the demo hosts go, Victor knows

That script returns a binary list of the online hosts, hence it's not exactly readable in notepad.

Had to think about this for a bit, but came to the conclusion that i want to keep the pubstats for licensed purposes only, so I won't add the demo host list.

Connecting to a demo host via command line is possible and yes, afaik there's an additional parameter to indicate the type of host you're about to join. But to be honest, I wouldn't know what that parameter is atm. Will have to ask.

Make a bat/shortcut with target as "F:\LFS_S2_ALPHA\LFS.exe" /join=host name /mode=demo
If the hostname has colors, you need to put them in too.

It's in the readme.txt under command line options

ahh /mode - that was it. It's actually listed under the host options, but not the guest options, though it should be there.

Thanx for responding. But if I don't get a List of the Demo-Servers, I won't need to start LfS in Demo-Mode.

Keep on the good work!

A big fan.

Quote from MonkOnHotTinRoof :

You can get list of demo servers by asking master server directly...

If you happen to know the protocol for talking to the master server, then by all means do share. Its certainly been something I;ve thought of reverse engineering.

Quote from the_angry_angel :

If you happen to know the protocol for talking to the master server, then by all means do share. Its certainly been something I;ve thought of reverse engineering.

Some fields are still missing, but I know enough to get list of all servers and their names, connections,... Finding meaning of other fields should be easy, since I didn't spent much time analyzing so far...
I will make simple .NET library to get a list of servers. And simple command line utility to show them.

I hope the devs won't mind connecting to master server directly . Not doing much traffic with it tho.. And it's not possible to differ where it comes from anyway .

Protocol seems pretty simple: You connect to master server, send request with some options (type of server, cars) and you get list of ip adresses and ports. Then just connect to every lfsserver from list and read its data (name, track,patch,connections,...).

Dude, you rock :up: I'm surprised that the master server doesnt keep more information tbh, but there we go Definately nice work

I've had this a while; I even have a client in PHP I was going to do something with, but given my current path it seems unlikely.

It is still not 100%, but it certainly isn't far off for the packets I've seen.

I have a working (well it worked at .5p7) PHP cient, although it takes roughly 100 odd seconds to get a full list. You can also get an S1 / S2 hosts list with it by grabbing the password from an ethereal packet dump of the master list (regular) request packet and supplying it to the class. I'm just going to update it with comments and such, and make sure it still works , then you can have it (unless the devs dont want you to ).

For now though, here is my reversal spec. Any questions, fire away.

To be honest, I think that knowing the master server protocol isnt such a good idea. We've got a (mostly) binary interface over HTTP (LFSWorld), and getting the data from the master host only has two advantages I can see - getting demo hosts (who cares though tbh), and no restriction in retreiving data (this assumes that the client restricts it, not the server. I could be wrong).

The con's by far out weigh the pro's tbh...

But cool nonetheless

Actually it is way slower than getting data from lfsworld. Main reason being you have to establish HOST_COUNT+1 sockets and send ((HOST_COUNT/16) + (HOST_COUNT * 2) + 1) packets (Given 300 hosts, that is 620 packets)

It in no way competes against the lfsworld data sources, and can only be used for a hostlist.

And yeah; cons do outweigh the pros, although you did miss a pro, which is why I did this in the first place. By requesting a list say once every 10 minutes, you get an extra bit of data lfsworld does not provide. IP and port combos. By joining a list from lfsworld with a list from the master list server (by servername), you can associate the IPs (not perfect, but it'll work). This will then allow for listing clients outside of LFS that will be able to ping the servers.

pinging lfs servers was asked here frequently...
but i doubt that the devs like to "ask" th master server directly...

I must admit it would be nice, but I dont think anyone wants to blindly give out IPs via LFSworld and querying the master server definately isnt a solution

One of the reasons we use hostnames only (host-names not internethostnames ) is so that ip's don't have to be shared. Even though a securely setup machine won't give a hoot that someone else knows their ip - it's just safer not having all LFS host ip's public domain.

Besides that, the only real pro would be the ability to ping a host via a website like anarchi-h said.

I know I don't have the demo hosts available via the pubstats, but it's something I've always had doubts about - I'm just not sure if demo-hosts should get additional support like that.
But obviously, you're free to ping hosts yourself. It's nice though that you have concerns about the master and they are legit concerns especially if more than a handful people will start doing continuous demo-host-list retreivals (and hosts themselves also get pinged - not just the master).
So it's in this context that I can be persuaded to include a demo hostlist option in the pubstat script, if it appears there is a real demand for it. But mind you, there will be no ip's available via pubstat, so the biggest pro that exists for getting a hostlist yourself, no longer applies when getting the hostlist from pubstat.

Quote from Anarchi-H :

Actually it is way slower than getting data from lfsworld. Main reason being you have to establish HOST_COUNT+1 sockets and send ((HOST_COUNT/16) + (HOST_COUNT * 2) + 1) packets (Given 300 hosts, that is 620 packets)

You can increase speed significantly by using agressive mutithreading. Actually the slowest thing is waiting for servers that don't respond to connection, but that can be solved by using asynchronous comm. and low timeouts.

Very nice spec !

That is one thing I don't get... I can see it is well intended, not to have hosts IP addresses distributed 'open-air' so to speak, but if I, or anyone else want to know the IP of every single host, or just a single host, all it takes is either "netstat -a", or a more refined method would be ethereal while the real LFS client requests a list (in the case of getting all IPs), or whilethe real LFS client is connecting / is connected to a server (in the case of a single host).

So anyone that could pose any real threat, and indeed about a million folk who don't could easily get the IP address anyway.

@MonkOnAHotTinRoof
Indeed, aggressive multi-threading would work providing that you have a server where you can host applications in a language that can multithread. PHP does not have that ability, although I have been looking in to ways of speeding it up by a kind of psuedo multi-thread app.
It basically chunks the data up and makes smaller (say 30 hosts) async HTTP requests to another script that gets and returns host data, but that is another topic completely.

And thank you, although I cannot take full credit. Victor kindly supplied me with his base script for requesting demo hosts (way back in S1), and I just translated it from PHP to a spec, corrected a few bits, filled in some blanks & updated it for S2.

So credit really goes to Victor.