tags:

views:

321

answers:

5

I am developing a chat website using jsp/servlet.I will be hosting my website on gooogle appengine .Now i have some doubts regarding whether to use server push or client pull technology

1)If i use server push and if i dont close the response of servlet will it cause the server to go slow?How many simultanious connection can a tyicall tomcat server can handle if i keep the socket open for the entire chat session between 2 clinets??

2)Will server push or clinet push be better??

+1  A: 

I don't know how are you thinking of achieving server push here. As far as I can see, server needs a request to respond over HTTP. So, when there is a request, server will respond to that.

Adeel Ansari
Add to that that the typical end user client is likely behind NAT and thus not reachable from the server to start with ;)
TomTom
Yes, rightly said. Thanks.
Adeel Ansari
"Reaching a client from a server to start with" , is beyond HTTP specification. NAT is not the real issue.If what you say is true, web client beneath a NAT box, will not be able to read web pages.
The Machine
A: 

Pull. Always pull.

I know it's a manufacturing-oriented book but the advice from Lean Thinking (Womack & Jones) is invaluable in any context (roughly, from memory):

Start by defining value, line up the activities that create value in the value-stream, create flow across the value-stream, let customers pull value from the value-stream, compete against perfection rather than other organizations

If I misquoted them, I apologize. Anyway, all of those principles can easily be applied in the development of any software product just as they could in the production of any physical product but the one that matters for you is pull.

Letting consumers of a service pull rather than pushing to them not only makes your programming model easier, it aligns activity with demand. You can still use queuing to load-level over time, if you have to, just the way you could with push but, this way, you have complete visibility into what, exactly happens in any given transaction.

I don't quite get your first question but the answer is still pull.

@MaxGuernseyIII: I think this is an oversimplification. I agree to your points, and actually I personally prefer pull-models, but there are valid reasons you would want to go with a push model. Sometimes you might want to go with a hybrid, like long polling. Anyways, "always pull" is probably an overstatement.
Enno Shioji
Pull is not a model. It is a principle. Push doesn't work when you're trying to get a boulder up hill. It doesn't work when you are trying to design a product. It doesn't work when you want to tow your car. It doesn't work in manufacturing. It doesn't even work in mythology (see my first "it doesn't work").I'll go one step further than "always pull" and add "if you think something other than pull is the right way to go, you're probably doing something else wrong."
I always push a glass door, and feel very inconvenient if it has been made for otherwise. I always prefer to push a baby stroller, or a shopping cart. There are many more example like this. Even in observer pattern publisher push the message to all observers. They don't pull it from publisher. Actually, push is much more effective, can you not see how they have been pushing their suggestions/ideas into our heads, since beginning. Now after this I tend to agree that, yours was an overstatement.
Adeel Ansari
Few parts of my retort is just a counter-argument with little amusement. I don't believe push is always a better way. Or pull means you are probably doing something else wrong.
Adeel Ansari
If you push a glass door you are doing it wrong.
@MaxGuernseyll: As demonstrated by your absurd examples (*e.g.* towing a car), I think you've completely misunderstood what the terms "push" and "pull" mean in this context.
A: 

If i use server push and if i dont close the response of servlet will it cause the server to go slow?

App Engine will not let you do that. You have to finish your response within thirty seconds, or it will be killed. The thirty seconds is also an edge case, most calculations they do (for quota and such) are based on a 75 millisecond response time.

How many simultanious connection can a tyicall tomcat server

Tomcat? I thought you are planning to use App Engine?

Thilo
i was planing to use either of those. either tomcat or appengine.So i cant do it with appengine as it will kill my response??
akshay
There must be an override to kill the timeout or make it longer. But this is a long poll scenario and that is normally handcoded with special servers. This is very unusual for a web server to handle and will not be efficient.
TomTom
"There must be an override to kill the timeout or make it longer". Well not an App Engine, at least nothing they let you fiddle with.
Thilo
A: 

The answer to your query depends on what underlying protocol you wish to use. Since you have mentioned JSP/servlets, your app will be implemented over the HTTP protocol.

HTTP is a protocol over TCP. TCP is connection oriented and remains alive, until the connection is ended. However, HTTP connections are persistent, only for the duration of a single request-response cycle. The TCP connection is broken after every request-response cycle. So that should answer your doubt with regards to how many socket connections a typical TOMCAT server will be able to handle. The connections will not be persistent, at all. They will only last the duration of a HTTP request-response cycle.

Given this basic idea, I would suggest , you use a client pull strategy, to implement your app. Even with server push, over HTTP, even though the name says "server push", it is always the web client that polls the server at regular intervals, which just gives an illusion of "server-push". HTTP specification mandates that the client makes a request to which the server responds.

I have considerable experience in developing chat applications (both mobile and web). Let me know , if you need any assistance. I will be more that willing to help.

The Machine
thanks for replying.Can i have ur msn or any other email id so that i can keep in touch with u??I would like to get ur help during for my development
akshay
"it is always the web client that polls the server at regular intervals": Well, there is the "Comet" approach, which does keep an HTTP connection to the server open indefinitely, so the server can continue to push data out.
Thilo
-1 for misinformation about what happens on the network layer. TCP connections for HTTP requests are NOT discarded after every request for many years now. Browsers pool them to avoid the contant opening / closing. This was introduce dIIRC with http 1.1. The server can disconnect, through, IIRC. Server Push is normally implemented as long poll and IS a viable technique, but one that can lead to TCP port exhaustion on the server.
TomTom
@akshay - let me know your mail address. I will get in touch with you.@Thilo - Thanks for the information. Will read on that.@TomTom - Thanks for the clarification. What is IS though ?
The Machine
@the machine : my mail id is [email protected] me on msn or mail me ur id
akshay
+1  A: 

If you are using a servlet (prior to 3.0), then I guess you'll have to go with pull because of the programming model of servlet. However, there ARE advantages in using a push model. Primarily, wasted load on server and the limitation in latency. That's why there are technologies such as comet. Servlet 3.0 also supports push model. These are commonly used in ajax based apps.

In fact I believe a push model is more suited for a chatting app. because of the fast response time (=better user experience) it can provide.

If you use a nio based implementation for push-model, you can support thousands or even more than 10k concurrent connections (obviously, your millage varies).

If you use a conventional IO based implementation, it will be likely in the range of hundreds of concurrent connections (don't take this estimation too seriously though. I'm just giving these numbers to give a very, very rough feeling).

As for tomcat, last time I checked, people were saying that it won't have a good push-model support until version 7.0. But I'm not following the current status so I'm not sure (Sorry, perhaps somebody else can help you on this). If that is the case, you might want to check out comet support of jetty.

grizzly and netty are also good NIO based network frameworks, but if you want to use JSP, and find that tomcat is not sufficient, I guess jetty would be the best bet.

edit: (some additional info) In this "push models", it's not like the server opens a connection to the client. The connection will be kept alive, and the server will push messages as it sees fit.

Also, it's not like there are only "push" and "pull" models. You can have a hybrid, like long polling.

Enno Shioji