This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [SPAM] Re: [Xen-users] multiple streaming servers in a xen cloud

To: francisco javier funes nieto <esencia@xxxxxxxxx>
Subject: Re: [SPAM] Re: [Xen-users] multiple streaming servers in a xen cloud
From: Tapas Mishra <mightydreams@xxxxxxxxx>
Date: Tue, 10 Aug 2010 16:49:00 +0530
Cc: Xen List <xen-users@xxxxxxxxxxxxxxxxxxx>, Simon Billis <simon@xxxxxxxxxx>
Delivery-date: Tue, 10 Aug 2010 04:20:21 -0700
Dkim-signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:received:in-reply-to :references:date:message-id:subject:from:to:cc:content-type; bh=0c4WE69owcdhwtVSNEnUNS0KHUpodX39rL30Hki9TM0=; b=vwDh/qVfZ+Nungx0Z5M6OjVg8T0rx97+mBaGLRNyLBC3bEDVU2rQpE5KsY1JsGfodW BUAoSjXBRc3llIoqjb/hhUmU/iYTE3BeV1Ke6qDe4J6C/4EOTryabHdhnswWkxniozmq OHI1lgw7HxQjrKT/IDagMbRYRg0FrldeGKJqU=
Domainkey-signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; b=j2v4yqIBdCdsQBmopwg5ttJiUXGlNf+jkqOK96RjtzAQMLRgft6rRnbCTLaIx+m66W sZGkM9igwnWucEL8NyW2MrLuhN8raxP+XgrORTB2nWLxIeLjtIohrWZ5J3Mh58oMUkna N/F78GGT7nxREXwMukp86TMi2q+1GOAApFK7E=
Envelope-to: www-data@xxxxxxxxxxxxxxxxxxx
In-reply-to: <AANLkTi=2NsCxiQX6BstsRtzS4GUApRetSOWCz50rFtKQ@xxxxxxxxxxxxxx>
List-help: <mailto:xen-users-request@lists.xensource.com?subject=help>
List-id: Xen user discussion <xen-users.lists.xensource.com>
List-post: <mailto:xen-users@lists.xensource.com>
List-subscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=subscribe>
List-unsubscribe: <http://lists.xensource.com/mailman/listinfo/xen-users>, <mailto:xen-users-request@lists.xensource.com?subject=unsubscribe>
References: <AANLkTink_W_3qb89QLqHgwuorAb2zg3GBCxn+dujUNuQ@xxxxxxxxxxxxxx> <0a3101cb37a6$3b8ff4e0$b2afdea0$@com> <AANLkTi=vu4tsxgVs1wj2CA_Atq_+NZpHzo3f007yQ-pS@xxxxxxxxxxxxxx> <0a4401cb37af$e3bf4a40$ab3ddec0$@com> <AANLkTikjwLx-0rEx1Nb8XYgKWz_1G2xt7CeDspMPdYty@xxxxxxxxxxxxxx> <AANLkTinEmTRbCBRYRDscSeXHNCreCj6a705aBjKuD33L@xxxxxxxxxxxxxx> <AANLkTi=H=R8LnXcnkHLPGuKTt6GJin_1wG66_qz2W+Mg@xxxxxxxxxxxxxx> <AANLkTi=2NsCxiQX6BstsRtzS4GUApRetSOWCz50rFtKQ@xxxxxxxxxxxxxx>
Sender: xen-users-bounces@xxxxxxxxxxxxxxxxxxx
I got this suggestion also from some one.
Since I had asked this question here so posting this message.

Pretty much nothing using "standard" approach.

Because the target server/application is deeply embedded into the RTMP traffic of that particular connection, you have to unpack it to know the target server/application. For this, you need to accept the connection in the front server. Once you did that, the only way to keep it functioning is to forward all future traffic/requests to the chosen server while keeping the initial connection alive. But, as I said, you will have 2 connections that you MUST maintain:

1. flash_player --> front_server
2. front_server --> target_lan_server

To make the problem even complex than it already is, the surrogate front_server MUST do the correct RTMP handshake. Otherwise you will not be able to play h264 content. And the sad part is that the information required (servername/application) only occurs on the connection AFTER the handshake is completed (in connection number 1)

Bottom line, very hard.

However, perfectly doable with rtmpd. But you have to hack the server pretty drastically to achieve that.

In any case, the big problem persists. You will have a single point of failure: front_server. To make the matter even worst, the major bottleneck will be the bandwidth. ALL traffic will go through one server:front_server. Unless you have multiple IPs/NetworkCards/InternetPipes in the front_server,

Xen-users mailing list