incubator-wave-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "HASEEN" <has...@blueyonder.co.uk>
Subject Re: Review Request: Websocket configurable in a different port and/or subdomain (#WAVE-357)
Date Sun, 17 Jun 2012 17:28:40 GMT
unsubscribe

----- Original Message ----- 
From: "Vicente J. Ruiz Jurado" <vjrj@ourproject.org>
To: "Yuri Zelikov" <vega113@gmail.com>; "Ali Lown" <ali@lown.me.uk>; 
"Michael MacFadden" <michael.macfadden@gmail.com>
Cc: "Vicente J. Ruiz Jurado" <vjrj@ourproject.org>; "wave" 
<wave-dev@incubator.apache.org>
Sent: Sunday, June 17, 2012 3:13 PM
Subject: Re: Review Request: Websocket configurable in a different port 
and/or subdomain (#WAVE-357)




> On June 17, 2012, 1:37 p.m., Michael MacFadden wrote:
> > This looks ok to me, but i do have some questions.  Assuming the CND 
> > example, how would this work.  It seems like the web socket address is 
> > inserted into the GXP context dynamically.  Would the output of the GXPs 
> > be cached at the CND?  Also, if using a CND would the client browser 
> > actually hit the front end address or would they be pointed to the CND?
> >
> > Can you describe what files and resources would be at the CDN node and 
> > how the client browser would interact with the CND and the live server? 
> > Especially regarding loading of the javascript and figuring out where to 
> > connect back to?

All the normal traffic of the client (except websocket traffic) comes from 
the CDN but depending on how aggressive is the CDN caching configured. The 
websocket traffic connects directly to other port/domain bypassing the CDN.

In our case, kune.cc points to our CDN (currently cloudflare), and 
www.kune.cc points to our server and is used for the websocket traffic. You 
can see with firebug which traffic comes directly from the CDN opening 
https://kune.cc. If you configure SSL the certificate should include both 
domains.

Looking the yesterday stats, half of the traffic is saved by the CDN.

Maybe someone knows other techniques to make services like Wave more 
scalable.


- Vicente J.


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/5375/#review8315
-----------------------------------------------------------


On June 17, 2012, 12:45 p.m., Vicente J. Ruiz Jurado wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/5375/
> -----------------------------------------------------------
>
> (Updated June 17, 2012, 12:45 p.m.)
>
>
> Review request for wave, Michael MacFadden, Yuri Zelikov, and Ali Lown.
>
>
> Description
> -------
>
> The idea is that the client uses two configurable listening addresses:
> - one for the normal traffic (all the common server petitions), the 
> current http_frontend_public_address
> - and a new one for the websocket traffic (that can be configured to a 
> different subdomain or port if it's necessary).
>
> That is, we would be able to split these two different traffics. This 
> would allow the use of proxies, caches or CDNs for the "normal traffic".
>
> Issue:
> https://issues.apache.org/jira/browse/WAVE-357
>
>
> Diffs
> -----
>
>   server-config.xml 5f39312
>   server.config.example 0d3da67
>   src/org/waveprotocol/box/server/CoreSettings.java d9b95ec
>   src/org/waveprotocol/box/server/gxp/WaveClientPage.gxp cea296a
>   src/org/waveprotocol/box/server/rpc/ServerRpcProvider.java 82c3c8d
>   src/org/waveprotocol/box/server/rpc/WaveClientServlet.java f8a95f2
>   src/org/waveprotocol/box/webclient/client/WebClient.java b16df98
>
> Diff: https://reviews.apache.org/r/5375/diff/
>
>
> Testing
> -------
>
> Tested with different ports/subdomains, for example with this in 
> /etc/hosts as websocket domain
> 127.0.0.1 ws.localhost
> but also tested in a production server.
>
>
> Thanks,
>
> Vicente J. Ruiz Jurado
>
>



Mime
View raw message