4 ms·

Same project I've been working on for the better part of 3 months, unfortunately: a web based chat using GWT to replace a flash based one. The primary reasons a

Same project I've been working on for the better part of 3 months, unfortunately: a web based chat using GWT to replace a flash based one. The primary reasons are: we wanted to control the source code and remove dependecy on third-party products and becase we want the chat to work on iPad so flash is out. Running into tons of stumbling blocks primarily around keeping the app near realtime and stable. It's GWT on the front-end, but .NET webservices on the backend. The existing flash based system has a custom server service and periodically dumps logs into SQL Server. We started off trying to write directly to SQL with our version but it wasn't fast enough and we were running into too many contention issues. Now we're throwing Memcached in the middle and it's much faster, but we're not entirely out of the woods. I'm thoroughly convinced HTTP just shouldn't be used for chat applications.

abi 16y ago
I'm surprised that was your conclusion. Why do you blame HTTP if the point of failure in your case seems to be the database?
- WesleyJohnson 16y ago
  That's a good question. I suppose it's because even with Memcached taking the load off the database, we still have other issues. For example, because we're dealing with stateless connections here, it's hard to know if a client is still connected to the chat. We're polling from the client to the webservice every few seconds to 'pull' new messages and also tell the server, "Hey, I'm still alive". In order to determine if the client has left we have to monitor the polling to see if there are gaps in the poll times. Some gaps are allowed of course, because of slower connections or connection timeouts, so it gets a little tricky trying to determine if a client is still on the other end. I attribute that to HTTP, but maybe it isn't entirely to blame. If we were dealing with sockets directly, I would know the client is disconnected as soon as the connection was terminated.
  - abi 16y ago
    To get new messages, you could simply use long polling so it becomes push instead of pull. For checking if the user is online (I'm assuming your clients are running in web browsers), you can use the onbeforeunload to send a HTTP request that the user is leaving. Of course, you still have to poll at regular intervals because the user might have put his computer to sleep which wouldn't trigger onbeforeunload but your interval can now even be as high as 60 seconds because most clients will trigger onbeforeunload.
tdfx 16y ago
The client interface is up to you, but no need to re-invent the serverside part: From http://xmpp.org/extensions/xep-0124.html http://xmpp.org/extensions/xep-0124.html This specification defines a transport protocol that emulates the semantics of a long-lived, bidirectional TCP connection between two entities (such as a client and a server) by efficiently using multiple synchronous HTTP request/response pairs without requiring the use of frequent polling or chunked responses. Drop in an existing XMPP chat server (or write your own if you must) and you should be good to go. A lot of high-volume sites are using this implementation for their web-based chat services.
- tdfx 16y ago
  As an aside: If you're not willing to make that substantial kind of change to your system at this point, I would at least recommend basing your messaging system on something that's designed to do it (i.e. a message queue) as opposed to a relational database. RabbitMQ has had quite good reviews from what I've seen, with clustering and persistence available.
ijoey 16y ago
I did this at the end of 2008. Try adding the fact that the chat service was on a different domain and they wanted to use it like a web service doing cross domain requests WITHOUT Flash.

abi 16y ago

I'm surprised that was your conclusion. Why do you blame HTTP if the point of failure in your case seems to be the database?

WesleyJohnson 16y ago
That's a good question. I suppose it's because even with Memcached taking the load off the database, we still have other issues. For example, because we're dealing with stateless connections here, it's hard to know if a client is still connected to the chat. We're polling from the client to the webservice every few seconds to 'pull' new messages and also tell the server, "Hey, I'm still alive". In order to determine if the client has left we have to monitor the polling to see if there are gaps in the poll times. Some gaps are allowed of course, because of slower connections or connection timeouts, so it gets a little tricky trying to determine if a client is still on the other end. I attribute that to HTTP, but maybe it isn't entirely to blame. If we were dealing with sockets directly, I would know the client is disconnected as soon as the connection was terminated.
- abi 16y ago
  To get new messages, you could simply use long polling so it becomes push instead of pull. For checking if the user is online (I'm assuming your clients are running in web browsers), you can use the onbeforeunload to send a HTTP request that the user is leaving. Of course, you still have to poll at regular intervals because the user might have put his computer to sleep which wouldn't trigger onbeforeunload but your interval can now even be as high as 60 seconds because most clients will trigger onbeforeunload.

tdfx 16y ago

The client interface is up to you, but no need to re-invent the serverside part: From http://xmpp.org/extensions/xep-0124.html http://xmpp.org/extensions/xep-0124.html This specification defines a transport protocol that emulates the semantics of a long-lived, bidirectional TCP connection between two entities (such as a client and a server) by efficiently using multiple synchronous HTTP request/response pairs without requiring the use of frequent polling or chunked responses. Drop in an existing XMPP chat server (or write your own if you must) and you should be good to go. A lot of high-volume sites are using this implementation for their web-based chat services.

tdfx 16y ago
As an aside: If you're not willing to make that substantial kind of change to your system at this point, I would at least recommend basing your messaging system on something that's designed to do it (i.e. a message queue) as opposed to a relational database. RabbitMQ has had quite good reviews from what I've seen, with clustering and persistence available.

ijoey 16y ago

I did this at the end of 2008. Try adding the fact that the chat service was on a different domain and they wanted to use it like a web service doing cross domain requests WITHOUT Flash.