From teranders@gmail.com Mon Dec 8 22:48:41 2014 Received: (at 684) by bugs.x2go.org; 8 Dec 2014 21:48:42 +0000 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on ymir.das-netzwerkteam.de X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,T_DKIM_INVALID,URIBL_BLOCKED autolearn=ham version=3.3.2 Received: from mail-vc0-f172.google.com (mail-vc0-f172.google.com [209.85.220.172]) by ymir.das-netzwerkteam.de (Postfix) with ESMTPS id 847865DB48 for <684@bugs.x2go.org>; Mon, 8 Dec 2014 22:48:40 +0100 (CET) Received: by mail-vc0-f172.google.com with SMTP id hq11so2628126vcb.17 for <684@bugs.x2go.org>; Mon, 08 Dec 2014 13:48:39 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=l/N3hbIVKfBm2ieY7m4Y6YHpsczNyd+oXSjM7Krl59Y=; b=wLpHpS3B3vjNMZ5rhFbr8/9zms7g1gl2ruz5Aqu5I595B9I+U3F3ySIry9rNicTLO4 DsVZI8bYCUlv2QocpOcI17JUYrR+DGz8XdVZszkAJpBFD2WCf2mHKBhhtITVdIPCY7hU xoPfCmQHIsiAEBpR4VwYjyiVloqU9i8uI01uDTPUAUcvoLq5EdhxP/3YdLZQF3CW/bAW 2DjTC4C67zW7ZaDZjsKSHL1uMzEeyrKp5Ne7AzSym5SxMhb2nRf+RCiXobIR6BrLiXr3 VfzxlGmT/rFKqMo4+r+J4E8lDcBGgQxoFITZx9c4FNr7wNtg/7l8HqXUZdhZaM/N5h7N oxNQ== MIME-Version: 1.0 X-Received: by 10.52.65.227 with SMTP id a3mr22509133vdt.32.1418075318852; Mon, 08 Dec 2014 13:48:38 -0800 (PST) Received: by 10.31.190.74 with HTTP; Mon, 8 Dec 2014 13:48:38 -0800 (PST) In-Reply-To: <914829209.13176.1418043985279.JavaMail.zimbra@tophouse.ru> References: <143861477.96320.1417796055431.JavaMail.zimbra@tophouse.ru> <1123477056.96337.1417796091693.JavaMail.zimbra@tophouse.ru> <20141206225605.Horde.h0QDOmvCPLZG5RzMvTt6XA3@mail.das-netzwerkteam.de> <92856184.99387.1417909528212.JavaMail.zimbra@tophouse.ru> <20141208072339.Horde.F4FcRmDw_W389jc-Roz0BA6@mail.das-netzwerkteam.de> <914829209.13176.1418043985279.JavaMail.zimbra@tophouse.ru> Date: Mon, 8 Dec 2014 22:48:38 +0100 Message-ID: Subject: Re: [X2Go-Dev] Bug#684: Bug#684: select_session offers offline servers to X2Go Client From: Terje Andersen To: Sergey Savko , 684@bugs.x2go.org Content-Type: multipart/alternative; boundary=20cf307f337aa521fe0509bb63aa --20cf307f337aa521fe0509bb63aa Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable 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 : > If you make a x2goclient connection to each farm server, then time will b= e > increased by seconds for such connection. > And if the server farm consist of more then 2-3 servers, then connection > time will increase strongly. > > ----- =D0=98=D1=81=D1=85=D0=BE=D0=B4=D0=BD=D0=BE=D0=B5 =D1=81=D0=BE=D0=BE= =D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B5 ----- > >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 > --20cf307f337aa521fe0509bb63aa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
Why not introduce a datastore which holds the current stat= e of all the servers in the server farm? Then the broker could query that o= ne for information to choose server from.
One could either use a separa= te database server for this or use something like sqlite (or mysql / postgr= esql / 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 way= s I'm thinking of right now:
1. Each server in the server far= m 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

Regardl= ess of the chosen implementation from one of those solutions would IMO:
* Make the broker-role easier to implement with regard to "adva= nced" setups
* Removes the wait for / time issue at connecti= on, or selection, process - just contact the datastore
* Makes it= possible to write a simple and central management app/webapp which one cou= ld 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 ti= me will increase strongly.

----- =D0=98=D1=81=D1=85=D0=BE=D0=B4=D0=BD=D0=BE=D0=B5 =D1=81=D0=BE=D0=BE= =D0=B1=D1=89=D0=B5=D0=BD=D0=B8=D0=B5 -----
>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

--20cf307f337aa521fe0509bb63aa--