Why not introduce a datastore which holds the current state of all the servers in the server farm? Then the broker could query that one for information to choose server from.
One could either use a separate database server for this or use something like sqlite (or mysql / postgresql / other) on each server host with some sort of replication (redundancy and avoids the need to contact one specific server - all can reply to the queries) or caching of the central datastore contents.

On how to update this information in the datastore there's two ways I'm thinking of right now:
1. Each server in the server farm writes to the datastore it's current status at regular intervals
2. One, or several (backup role if the "master" should fail) server(s) have been given the responsibility to query the servers in the farm for their status at regular intervals

Regardless of the chosen implementation from one of those solutions would IMO:
* Make the broker-role easier to implement with regard to "advanced" setups
* Removes the wait for / time issue at connection, or selection, process - just contact the datastore
* Makes it possible to write a simple and central management app/webapp which one could administer the entire server farm
* other possibilites

Regards,
Terje


2014-12-08 14:06 GMT+01:00 Sergey Savko <savko@tophouse.ru>:
If you make a x2goclient connection to each farm server, then time will be increased by seconds for such connection.
And if the server farm consist of more then 2-3 servers, then connection time will increase strongly.

----- Исходное сообщение -----
>Plus, I still think, that X2Go Client should request another machine,
>if the provided server was offline and more than one server is
>configured in the broker's session profile.
_______________________________________________
x2go-dev mailing list
x2go-dev@lists.x2go.org
http://lists.x2go.org/listinfo/x2go-dev