RPC connections over HTTPS (Comet with GWT)
idan...@gmail.com
I would like to use my GWT application over https (for secure needs)
My application need to hold about 60-80 widgets (composites)
Each composite need to get his information from the Server using RPC
My question:
1. is there any know problematic issues about
a. https
b. many composites on single page (I would like to use 60-80)
c. many connections from the same page (each composite need is own
connections)
2. Because https need verifications in each connection,
I would like to know if there is option to use Comet (Connection-
Keep-Alive option) and if so,
Can some one write/link any code sample of using Comet on GWT?
3. How the Ajax / GWT manage the HTTPConnections -
Is there a pool of Live-Connections? or it create connection each
time it needed?
Thanks,
Idan
Jason Essington
On May 7, 2007, at 10:48 AM, idan...@gmail.com wrote:
>
> Hello,
>
> I would like to use my GWT application over https (for secure needs)
> My application need to hold about 60-80 widgets (composites)
> Each composite need to get his information from the Server using RPC
>
> My question:
> 1. is there any know problematic issues about
> a. https
Nope, https works just fine ... one thing to note however is that
content sent via https is not cached by browsers, this means that
your application will not be cached like it would over HTTP.
I'm playing with the new bootstrap code in GWT 1.4, and it turns out
that it is possible to load your host page from a HTTPS url, but load
the javascript from a HTTP url (so that it'll be cached) then run the
RPC via https.
> b. many composites on single page (I would like to use 60-80)
nope, works fine. I've got pages with hundreds of widgets of all types.
> c. many connections from the same page (each composite need is own
> connections)
You'll get 2. it is a browser thing, not a GWT thing. So what you are
really saying is each widget is going to be performing its own RPC.
All of those RPCs will have to happen over the two connections that
the browser allows you. However, you will never actually need to
worry too much about the underlying connections anyway.
>
> 2. Because https need verifications in each connection,
> I would like to know if there is option to use Comet (Connection-
> Keep-Alive option) and if so,
> Can some one write/link any code sample of using Comet on GWT?
>
> 3. How the Ajax / GWT manage the HTTPConnections -
> Is there a pool of Live-Connections? or it create connection each
> time it needed?
Basically, the browser will allow you to have two connections open at
a time. which means that you'll not want each of your widgets to be
"holding" the connection. basically the'll need to get their data
then move on.
-jason
rb
cause mixed content warnings?
On May 7, 1:55 pm, Jason Essington <jason.essing...@gmail.com> wrote:
Abdullah Jibaly
only happen when it's the other way around (non-https page loading
https content). Anyone know about this?
Thanks,
Abdullah
Jason Essington
FF, Safari, and Opera do not
-jason
Reinier Zwitserloot
Connection: keep-alive has absolutely zip squat to do with comet.
Completely unrelated.
Connection: keep-alive allows you to SEQUENTIALLY multiplex HTTP
connections over a single TCP/IP connection versus the HTTP/1.0 common
tactic of opening a new TCP/IP connection for each HTTP connection.
Note the sequentially word there: Even with Connection: keep-alive,
you can't send another HTTP request over the TCP/IP connection until
the previous one is -COMPLETELY DONE-: request has been sent and is
completed, and the response is received in full.
COMET on the other hand is something entirely different: COMET is the
act of turning the response into an endless bytestream - normally HTTP
delivers set chunks of data: e.g. you request for a file: The server
already knows what that data (the file content) is beforehand, it just
needs to fetch it and toss it down the pipes. Similar stuff happends
for e.g. a GWT-RPC query for a db record. That's normal HTTP stuff.
COMET is the twist on this story: Instead of replying, you as a server
act like you are overloaded and dead slow, and you don't send any
bytes back, you just sit there, waiting. Then you send a little data,
not everything, and wait some more. This process is similar to chat
rooms - the data you want to send doesn't even exist yet at the time
the request was made.
comet is problematic for three reasons:
1. in IE it is extremely hard to check the content-sent-so-far of
dynamic connections. For example, the 'responseText' field of an ajax
connection (XmlHttpRequest) is empty until the response is done, but
comet is all about the response not being done yet.
2. normal web server paradigms are threaded. If you then do the
'waiting for more data' bit as a simple thread freeze, your apache
will conk out and overload after serving up only 50 customers, which
is piss poor performance, obviously. You really need a non-threaded
paradigm, one where your servlet can return from its doGet/doPost
method without closing the connection. Jetty with continuations can do
it, and a few other web hacks, but e.g. PHP simply cannot do this,
period. You must dedicate a whole thread to each comet connection,
which doesn't scale at all.
3. Browsers only allow 2 connections per hostname. The nature of a
comet connection is to remain open - and an open connection is taking
up a full slot. Even with Connection: keep-alive you can't use that
connection for other data, as Connection: keep-alive only does stuff
once a request is completed, and comet requests take a long time to
complete, that's the point of them. This means in practice that an
open comet connection + loading some image someplace = no more data
for you. a third connection (e.g. an AJAX call) will simply be placed
on hold until the image is done loading or the comet connection
completes.
4. The web wasn't designed with comet in mind. There is no low-impact
'stream flush' so a web proxy buffering your data somewhere in the
middle can mean a comet info packet doesn't arrive on demand, but only
when you close down the stream. Lots of intermediary proxies and
browsers will simply think you as a server crashed and call timeout,
eventhough you didn't crash but were just waiting for e.g. someone in
a chat box to say something. The strategies to read out dynamic
delayed response connections are generally pretty bad: IE doesn't play
ball well, and regardless of that, most solutions involve parsing an
ever-growing string, which becomes slower and slower.
The solutions for that last one are legion - one common tactic is to
host your images on img.yourserver.com which is considered different.
Another tactic is to multiplex all comet traffic on one connection -
this is in fact what the name 'comet' really refers to: It's a
protocol which multiplexes unrelated 'on-demand/server-push' data
streams onto a single data stream. Web server implementations are
called 'cometd', and there is one for e.g. Jetty.
cometd is often overkill. However, in your situation, if you really
mean delayed response connections for 60 to 80 widgets, it's -exactly-
what you need, and nothing else could possibly work, pretty much.
A common tactic that solves a couple of comet problems is to use
delayed single packet response connections: The idea is this: Imagine
a chatroom. Instead of having a comet connection that keeps sending
the text, you as a server only reply with 1 chat line per connection,
but you do this in a delayed fashion. For example, let's say I'm the
client and I just received the 800th line of the conversation. I now
make a server request:
www.webchat.com/someChatRoomName/?idx=801
in other words, I ask for the 801st line.
The web server receives the request and notices that line 801 hasn't
been spoken yet; the client is actually up to date. Instead of
responding with 'no 801st line', forcing the client to start' polling'
you, asking the same request every second, the server does something
different: it freezes the connection until someone says something.
When someone says something, the server responds with the text, then
CLOSES the connection, forcing intermediate proxies to stop buffering
and send it on, in the process, and you dodge IE's inability to grant
access to data streams in progress. This doesn't solve the 2
connections per host problem though, and it doesn't solve the problem
of web servers not designed for this stuff not being capable of
handling more than 50ish simultaneous connections.
If you are confused and generally feeling that comet is extremely
difficult, YOU ARE RIGHT - it is. Comet is not for the faint of heart.
You can do a lot of cool stuff with it though.
Abdullah Jibaly
material on this list, makes a great reference!
Thanks a lot for your contributions,
Abdullah