Hello,
I am trying to find a way to implement ajax with a given socket server.
Basically I have a support system that is fully integrated, but I can not
stand the "JAVA" chat client because of the security warning and load
time.
So I figured I would look towards ajax especially since it has XML
capabilites.
I have the whitepaper on the socket server, this socket server is on the
same webserver that the pop-up client will be hosted from it is just on a
different port obviously than the http server.
The server is done like so:
Sent by the Server to Client immediately after connection is established.
The client must reply with a properly populated authreply message:
<auracle>
<type>authrequest</type>
</auracle>
AUTHREPLY
Sent to server immediately after authrequest is received. The reply should
contain USERNAME and EMAIL which the client is responsible for collecting.
<auracle>
<type>authreply</type>
<username>USERNAME</username>
<email>EMAIL</email>
<category>A for admin, otherwise send category id
(C1,S2,.)</category>
<HID>reserved for internal use, send 0 if unavailable</HID>
<!-- if this request was made by a logged-in user (logged into ASE) -->
<memberid>ASE customer id</memberid>
<xchash>XC-generated user hash</ xchash >
<!-- end logged-user specific data -->
</auracle>
And so on.. I am new to this sort of thing can someone please point me in
the right direction
Thank you ahead of time.
On 15/09/05, Stephen Major <smajor@gmail.com> wrote:> I am trying to find a way to implement ajax with a given socket server.The real name is XMLHttpRequest. Thous the communication has to use the HTTP protocol. So no chance. Bye, Martin
It''s not entirely impossible -- your AJAX implementation would have to talk to a Web Service (SOAP, XML-RPC, REST) which in turn would do the heavy lifting invovled in communicating with the chat server. The downside would be adding yet another layer (like an onion) to this process. (For the record, onions stink, and sting my eyes. ;) On 9/15/05, Martin Bialasinski <klingeling@gmail.com> wrote:> > On 15/09/05, Stephen Major <smajor@gmail.com> wrote: > > > I am trying to find a way to implement ajax with a given socket server. > > The real name is XMLHttpRequest. Thous the communication has to use > the HTTP protocol. So no chance. > > Bye, > Martin > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails-spinoffs/attachments/20050915/1aa82cfe/attachment.html
> I am trying to find a way to implement ajax with a given socket server. > Basically I have a support system that is fully integrated, but I can not > stand the "JAVA" chat client because of the security warning and load > time. > So I figured I would look towards ajax especially since it has XML > capabilites. > >In Opera and Firefox, the XML request thingy is limited to accessing addresses on the same domain, subdomain and port number. So if you want to access the socket through Ajax, you will have to setup a proxy that pushes the socket data and the web server data through the same port. This is pretty heavy stuff to configure, especially for chat, because most proxies use buffering. I am currently working in this direction, I will let the list know about progresses. Right now I am trying this out with the apache mod_proxy, which is quite frankly a pain in the backside. ______________________________________________________________ Verschicken Sie romantische, coole und witzige Bilder per SMS! Jetzt bei WEB.DE FreeMail: http://f.web.de/?mc=021193
Buddy unless you have something intelligent to offer to the disussion please do not reply, You obviously do not know what you are talking about, or b you are so closed minded in the subject that you do not think outside the box, AJAX is used for client side scripts to call procedures to server side scripts, this could be done by calling php functions that handle the socket connect. Utlizing ajax to properly form the xml, being that the the socket server is a xml socket server, would seem like a good way to handle the client without a refresh like current php chat clients that refresh and tag a database server. Bye! -----Original Message----- From: rails-spinoffs-bounces@lists.rubyonrails.org [mailto:rails-spinoffs-bounces@lists.rubyonrails.org] On Behalf Of Martin Bialasinski Sent: Thursday, September 15, 2005 11:02 AM To: rails-spinoffs@lists.rubyonrails.org Subject: Re: [Rails-spinoffs] Ajax to sockets. On 15/09/05, Stephen Major <smajor@gmail.com> wrote:> I am trying to find a way to implement ajax with a given socket server.The real name is XMLHttpRequest. Thous the communication has to use the HTTP protocol. So no chance. Bye, Martin _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Sorry, but you don''t know what you''re talking about. "XMLHTTP is a set of APIs that can be used by JavaScript, JScript, VBScript and other web browser scripting languages to transfer XML or other data to and from a web server using HTTP."[1] So, it''s the HTTP protocol only (and for security reasons, only with the originating web server). Thomas [1] http://en.wikipedia.org/wiki/XMLHttpRequest Am 15.09.2005 um 22:48 schrieb Stephen Major:> Buddy unless you have something intelligent to offer to the > disussion please > do not reply, > > You obviously do not know what you are talking about, or b you are > so closed > minded in the subject that you do not think outside the box, AJAX > is used > for client side scripts to call procedures to server side scripts, > this > could be done by calling php functions that handle the socket connect. > Utlizing ajax to properly form the xml, being that the the socket > server is > a xml socket server, would seem like a good way to handle the > client without > a refresh like current php chat clients that refresh and tag a > database > server.
You are very narrow minded, do some research on php and sockets, then tell me I cannot utilize ajax to call a php function that makes the connection, all I am trying to do is get other ideas of how they would accomplish such a task. So do yourself a favor an but out, there already has been repolies from others that saud they were working on similar projects. -----Original Message----- From: rails-spinoffs-bounces@lists.rubyonrails.org [mailto:rails-spinoffs-bounces@lists.rubyonrails.org] On Behalf Of Thomas Fuchs Sent: Thursday, September 15, 2005 2:30 PM To: rails-spinoffs@lists.rubyonrails.org Subject: Re: [Rails-spinoffs] Ajax to sockets. Sorry, but you don''t know what you''re talking about. "XMLHTTP is a set of APIs that can be used by JavaScript, JScript, VBScript and other web browser scripting languages to transfer XML or other data to and from a web server using HTTP."[1] So, it''s the HTTP protocol only (and for security reasons, only with the originating web server). Thomas [1] http://en.wikipedia.org/wiki/XMLHttpRequest Am 15.09.2005 um 22:48 schrieb Stephen Major:> Buddy unless you have something intelligent to offer to the disussion > please do not reply, > > You obviously do not know what you are talking about, or b you are so > closed minded in the subject that you do not think outside the box, > AJAX is used for client side scripts to call procedures to server side > scripts, this could be done by calling php functions that handle the > socket connect. > Utlizing ajax to properly form the xml, being that the the socket > server is a xml socket server, would seem like a good way to handle > the client without a refresh like current php chat clients that > refresh and tag a database server._______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
Let me re-phrase my last post, I think you mis-understand what I am asking about, I am not asking to use the technology to actually do the connecting, I am talking about a client interface that utilizes ajax for refreshless chat client, with a backend on the server that handles the calls. Whether it be php or whatever, I want to see other peoples input in how they would go about it, before I jump head first into a new project. -----Original Message----- From: rails-spinoffs-bounces@lists.rubyonrails.org [mailto:rails-spinoffs-bounces@lists.rubyonrails.org] On Behalf Of Thomas Fuchs Sent: Thursday, September 15, 2005 2:30 PM To: rails-spinoffs@lists.rubyonrails.org Subject: Re: [Rails-spinoffs] Ajax to sockets. Sorry, but you don''t know what you''re talking about. "XMLHTTP is a set of APIs that can be used by JavaScript, JScript, VBScript and other web browser scripting languages to transfer XML or other data to and from a web server using HTTP."[1] So, it''s the HTTP protocol only (and for security reasons, only with the originating web server). Thomas [1] http://en.wikipedia.org/wiki/XMLHttpRequest Am 15.09.2005 um 22:48 schrieb Stephen Major:> Buddy unless you have something intelligent to offer to the disussion > please do not reply, > > You obviously do not know what you are talking about, or b you are so > closed minded in the subject that you do not think outside the box, > AJAX is used for client side scripts to call procedures to server side > scripts, this could be done by calling php functions that handle the > socket connect. > Utlizing ajax to properly form the xml, being that the the socket > server is a xml socket server, would seem like a good way to handle > the client without a refresh like current php chat clients that > refresh and tag a database server._______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs
You can''t do XML socket connections with XmlHttpRequests. Although your original post doesn''t make this clear, it looks like you understand this fine. You will not be able to just replace the java client, as you can''t write a client app to interface with the socket server purely in javascript. So you will have a proxy app which will open a socket to the server and do all that communication in the background, buffering messages ready for the JS client to grab them. Then you will have to poll that proxy app at intervals with javascript to get/send the messages in the chat. I did something like this as a proof of concept for a system a while back and found that continuous polling didn''t work very well due to the nature of conversations: Long periods of silence followed by periods of active conversation. To make it responsive you end up with a short polling interval, but this is then very wasteful when there''s not much going on in the room. Ideally, you want to poll the server only when there is a message to receive, obviously this is not possible without a socket connection! To this ends I wrote a ''decaying poll'' [1] in javascript a while back which you may or may not find useful. This was prior to Prototype etc... so I could probably do with revisiting it to integrate it in at some point if anyone thinks it could be useful in there? This allows you to poll the server and if there are no messages to wait longer till the next poll. So you could start off polling every second and gradually decay down to a 5 to 10 second poll when there is periods of quiet. Once a message is received, then you reset the poll. Basically the opposite of the TCP slow start algorithm. It''s fast start instead. In this way, periods of active conversation are polled regularly to cut down on lag, but periods of silence have little polling and thus cuts down on resources - both server and client. This approach worked very well and seemed to fit the conversational model quite nicely. In adition to this polling, we wrote a socket client in Flash which sits on the same page as the chat. If the user has flash enabled then we don''t poll at all and the Flash script tells the javascript when there is a message waiting. In this way the JS only asks for content when there is some waiting. If the user doesn''t have flash, it falls back on the decaying poll. That ended up being a bit longer than planned, but hope some of that helps! [1] http://livsey.org/2005/06/07/decaying-poll-in-javascript/ -- R.Livsey http://livsey.org Stephen Major wrote:>Let me re-phrase my last post, > >I think you mis-understand what I am asking about, I am not asking to use >the technology to actually do the connecting, I am talking about a client >interface that utilizes ajax for refreshless chat client, with a backend on >the server that handles the calls. Whether it be php or whatever, I want to >see other peoples input in how they would go about it, before I jump head >first into a new project. > >-----Original Message----- >From: rails-spinoffs-bounces@lists.rubyonrails.org >[mailto:rails-spinoffs-bounces@lists.rubyonrails.org] On Behalf Of Thomas >Fuchs >Sent: Thursday, September 15, 2005 2:30 PM >To: rails-spinoffs@lists.rubyonrails.org >Subject: Re: [Rails-spinoffs] Ajax to sockets. > >Sorry, but you don''t know what you''re talking about. > >"XMLHTTP is a set of APIs that can be used by JavaScript, JScript, VBScript >and other web browser scripting languages to transfer XML or other data to >and from a web server using HTTP."[1] > >So, it''s the HTTP protocol only (and for security reasons, only with the >originating web server). > >Thomas > >[1] http://en.wikipedia.org/wiki/XMLHttpRequest > >Am 15.09.2005 um 22:48 schrieb Stephen Major: > > > >>Buddy unless you have something intelligent to offer to the disussion >>please do not reply, >> >>You obviously do not know what you are talking about, or b you are so >>closed minded in the subject that you do not think outside the box, >>AJAX is used for client side scripts to call procedures to server side >>scripts, this could be done by calling php functions that handle the >>socket connect. >>Utlizing ajax to properly form the xml, being that the the socket >>server is a xml socket server, would seem like a good way to handle >>the client without a refresh like current php chat clients that >>refresh and tag a database server. >> >> > >_______________________________________________ >Rails-spinoffs mailing list >Rails-spinoffs@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > >_______________________________________________ >Rails-spinoffs mailing list >Rails-spinoffs@lists.rubyonrails.org >http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > > > >
Another option is to use keep-alive requests to your server-side proxy app: the JS client issues a poll, but uses keep-alive. The proxy then doesn''t send any response until it has one. The JS client then gets ''woken up'' as soon as there''s something for it to do (because it finally receives a response from the proxy). Actually, you could do that without keep-alive, as long as the proxy blocks on poll requests it can''t yet answer, without closing the connection. Then, the JS client polls the proxy and either (a) gets a response (possibly after some delay) or (b) gets a connection timeout and re-polls. The trade-off is between how frequently the proxy receives requests (in a ''poll / return immediately'' implementation) vs. how many connections to the proxy get held open at once. If you have a lot of chat clients, you might want to back off the rate at which the JS clients re-poll after a timeout. Hope that makes sense, I''m too tired to explain it better ;-) L. On 15-Sep-05, at 10:33 PM, Richard Livsey wrote:> You can''t do XML socket connections with XmlHttpRequests. Although > your original post doesn''t make this clear, it looks like you > understand this fine. > > You will not be able to just replace the java client, as you can''t > write a client app to interface with the socket server purely in > javascript. So you will have a proxy app which will open a socket > to the server and do all that communication in the background, > buffering messages ready for the JS client to grab them. Then you > will have to poll that proxy app at intervals with javascript to > get/send the messages in the chat. > > I did something like this as a proof of concept for a system a > while back and found that continuous polling didn''t work very well > due to the nature of conversations: > > Long periods of silence followed by periods of active conversation. > > To make it responsive you end up with a short polling interval, but > this is then very wasteful when there''s not much going on in the room. > > Ideally, you want to poll the server only when there is a message > to receive, obviously this is not possible without a socket > connection! > > To this ends I wrote a ''decaying poll'' [1] in javascript a while > back which you may or may not find useful. This was prior to > Prototype etc... so I could probably do with revisiting it to > integrate it in at some point if anyone thinks it could be useful > in there? > > This allows you to poll the server and if there are no messages to > wait longer till the next poll. So you could start off polling > every second and gradually decay down to a 5 to 10 second poll when > there is periods of quiet. Once a message is received, then you > reset the poll. Basically the opposite of the TCP slow start > algorithm. It''s fast start instead. > > In this way, periods of active conversation are polled regularly to > cut down on lag, but periods of silence have little polling and > thus cuts down on resources - both server and client. > > This approach worked very well and seemed to fit the conversational > model quite nicely. > > In adition to this polling, we wrote a socket client in Flash which > sits on the same page as the chat. If the user has flash enabled > then we don''t poll at all and the Flash script tells the javascript > when there is a message waiting. In this way the JS only asks for > content when there is some waiting. If the user doesn''t have flash, > it falls back on the decaying poll. > > That ended up being a bit longer than planned, but hope some of > that helps! > > [1] http://livsey.org/2005/06/07/decaying-poll-in-javascript/ > > -- > R.Livsey > http://livsey.org > > > > Stephen Major wrote: > > >> Let me re-phrase my last post, >> >> I think you mis-understand what I am asking about, I am not asking >> to use >> the technology to actually do the connecting, I am talking about a >> client >> interface that utilizes ajax for refreshless chat client, with a >> backend on >> the server that handles the calls. Whether it be php or whatever, >> I want to >> see other peoples input in how they would go about it, before I >> jump head >> first into a new project. >> >> -----Original Message----- >> From: rails-spinoffs-bounces@lists.rubyonrails.org >> [mailto:rails-spinoffs-bounces@lists.rubyonrails.org] On Behalf Of >> Thomas >> Fuchs >> Sent: Thursday, September 15, 2005 2:30 PM >> To: rails-spinoffs@lists.rubyonrails.org >> Subject: Re: [Rails-spinoffs] Ajax to sockets. >> >> Sorry, but you don''t know what you''re talking about. >> >> "XMLHTTP is a set of APIs that can be used by JavaScript, JScript, >> VBScript >> and other web browser scripting languages to transfer XML or other >> data to >> and from a web server using HTTP."[1] >> >> So, it''s the HTTP protocol only (and for security reasons, only >> with the >> originating web server). >> >> Thomas >> >> [1] http://en.wikipedia.org/wiki/XMLHttpRequest >> >> Am 15.09.2005 um 22:48 schrieb Stephen Major: >> >> >> >>> Buddy unless you have something intelligent to offer to the >>> disussion please do not reply, >>> >>> You obviously do not know what you are talking about, or b you >>> are so closed minded in the subject that you do not think outside >>> the box, AJAX is used for client side scripts to call procedures >>> to server side scripts, this could be done by calling php >>> functions that handle the socket connect. >>> Utlizing ajax to properly form the xml, being that the the socket >>> server is a xml socket server, would seem like a good way to >>> handle the client without a refresh like current php chat clients >>> that refresh and tag a database server. >>> >>> >> >> _______________________________________________ >> Rails-spinoffs mailing list >> Rails-spinoffs@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >> >> _______________________________________________ >> Rails-spinoffs mailing list >> Rails-spinoffs@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >> >> >> >> >> > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >-- Laurie Harper Open Source advocate, Java geek: http://www.holoweb.net/laurie Founder, Zotech Software: http://www.zotechsoftware.com/
Or write an applet? ;) Sorry, I couldn''t help it... On 9/15/05, Laurie Harper <laurie@holoweb.net> wrote:> > Another option is to use keep-alive requests to your server-side > proxy app: the JS client issues a poll, but uses keep-alive. The > proxy then doesn''t send any response until it has one. The JS client > then gets ''woken up'' as soon as there''s something for it to do > (because it finally receives a response from the proxy). > > Actually, you could do that without keep-alive, as long as the proxy > blocks on poll requests it can''t yet answer, without closing the > connection. Then, the JS client polls the proxy and either (a) gets a > response (possibly after some delay) or (b) gets a connection timeout > and re-polls. > > The trade-off is between how frequently the proxy receives requests > (in a ''poll / return immediately'' implementation) vs. how many > connections to the proxy get held open at once. If you have a lot of > chat clients, you might want to back off the rate at which the JS > clients re-poll after a timeout. > > Hope that makes sense, I''m too tired to explain it better ;-) > > L. > > On 15-Sep-05, at 10:33 PM, Richard Livsey wrote: > > > You can''t do XML socket connections with XmlHttpRequests. Although > > your original post doesn''t make this clear, it looks like you > > understand this fine. > > > > You will not be able to just replace the java client, as you can''t > > write a client app to interface with the socket server purely in > > javascript. So you will have a proxy app which will open a socket > > to the server and do all that communication in the background, > > buffering messages ready for the JS client to grab them. Then you > > will have to poll that proxy app at intervals with javascript to > > get/send the messages in the chat. > > > > I did something like this as a proof of concept for a system a > > while back and found that continuous polling didn''t work very well > > due to the nature of conversations: > > > > Long periods of silence followed by periods of active conversation. > > > > To make it responsive you end up with a short polling interval, but > > this is then very wasteful when there''s not much going on in the room. > > > > Ideally, you want to poll the server only when there is a message > > to receive, obviously this is not possible without a socket > > connection! > > > > To this ends I wrote a ''decaying poll'' [1] in javascript a while > > back which you may or may not find useful. This was prior to > > Prototype etc... so I could probably do with revisiting it to > > integrate it in at some point if anyone thinks it could be useful > > in there? > > > > This allows you to poll the server and if there are no messages to > > wait longer till the next poll. So you could start off polling > > every second and gradually decay down to a 5 to 10 second poll when > > there is periods of quiet. Once a message is received, then you > > reset the poll. Basically the opposite of the TCP slow start > > algorithm. It''s fast start instead. > > > > In this way, periods of active conversation are polled regularly to > > cut down on lag, but periods of silence have little polling and > > thus cuts down on resources - both server and client. > > > > This approach worked very well and seemed to fit the conversational > > model quite nicely. > > > > In adition to this polling, we wrote a socket client in Flash which > > sits on the same page as the chat. If the user has flash enabled > > then we don''t poll at all and the Flash script tells the javascript > > when there is a message waiting. In this way the JS only asks for > > content when there is some waiting. If the user doesn''t have flash, > > it falls back on the decaying poll. > > > > That ended up being a bit longer than planned, but hope some of > > that helps! > > > > [1] http://livsey.org/2005/06/07/decaying-poll-in-javascript/ > > > > -- > > R.Livsey > > http://livsey.org > > > > > > > > Stephen Major wrote: > > > > > >> Let me re-phrase my last post, > >> > >> I think you mis-understand what I am asking about, I am not asking > >> to use > >> the technology to actually do the connecting, I am talking about a > >> client > >> interface that utilizes ajax for refreshless chat client, with a > >> backend on > >> the server that handles the calls. Whether it be php or whatever, > >> I want to > >> see other peoples input in how they would go about it, before I > >> jump head > >> first into a new project. > >> > >> -----Original Message----- > >> From: rails-spinoffs-bounces@lists.rubyonrails.org > >> [mailto:rails-spinoffs-bounces@lists.rubyonrails.org] On Behalf Of > >> Thomas > >> Fuchs > >> Sent: Thursday, September 15, 2005 2:30 PM > >> To: rails-spinoffs@lists.rubyonrails.org > >> Subject: Re: [Rails-spinoffs] Ajax to sockets. > >> > >> Sorry, but you don''t know what you''re talking about. > >> > >> "XMLHTTP is a set of APIs that can be used by JavaScript, JScript, > >> VBScript > >> and other web browser scripting languages to transfer XML or other > >> data to > >> and from a web server using HTTP."[1] > >> > >> So, it''s the HTTP protocol only (and for security reasons, only > >> with the > >> originating web server). > >> > >> Thomas > >> > >> [1] http://en.wikipedia.org/wiki/XMLHttpRequest > >> > >> Am 15.09.2005 um 22:48 schrieb Stephen Major: > >> > >> > >> > >>> Buddy unless you have something intelligent to offer to the > >>> disussion please do not reply, > >>> > >>> You obviously do not know what you are talking about, or b you > >>> are so closed minded in the subject that you do not think outside > >>> the box, AJAX is used for client side scripts to call procedures > >>> to server side scripts, this could be done by calling php > >>> functions that handle the socket connect. > >>> Utlizing ajax to properly form the xml, being that the the socket > >>> server is a xml socket server, would seem like a good way to > >>> handle the client without a refresh like current php chat clients > >>> that refresh and tag a database server. > >>> > >>> > >> > >> _______________________________________________ > >> Rails-spinoffs mailing list > >> Rails-spinoffs@lists.rubyonrails.org > >> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > >> > >> _______________________________________________ > >> Rails-spinoffs mailing list > >> Rails-spinoffs@lists.rubyonrails.org > >> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > >> > >> > >> > >> > >> > > _______________________________________________ > > Rails-spinoffs mailing list > > Rails-spinoffs@lists.rubyonrails.org > > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > > > > -- > Laurie Harper > Open Source advocate, Java geek: http://www.holoweb.net/laurie > Founder, Zotech Software: http://www.zotechsoftware.com/ > > > > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://wrath.rubyonrails.org/pipermail/rails-spinoffs/attachments/20050915/75f524ac/attachment.html
That is what we are trying to replace is the applet, it is for a live help system, and new customers do not like to wait for a load time and a security warning to ask you a question ________________________________ From: rails-spinoffs-bounces@lists.rubyonrails.org [mailto:rails-spinoffs-bounces@lists.rubyonrails.org] On Behalf Of Jesse Kuhnert Sent: Thursday, September 15, 2005 8:03 PM To: rails-spinoffs@lists.rubyonrails.org Subject: Re: [Rails-spinoffs] Ajax to sockets. Or write an applet? ;) Sorry, I couldn''t help it... On 9/15/05, Laurie Harper <laurie@holoweb.net> wrote: Another option is to use keep-alive requests to your server-side proxy app: the JS client issues a poll, but uses keep-alive. The proxy then doesn''t send any response until it has one. The JS client then gets ''woken up'' as soon as there''s something for it to do (because it finally receives a response from the proxy). Actually, you could do that without keep-alive, as long as the proxy blocks on poll requests it can''t yet answer, without closing the connection. Then, the JS client polls the proxy and either (a) gets a response (possibly after some delay) or (b) gets a connection timeout and re-polls. The trade-off is between how frequently the proxy receives requests (in a ''poll / return immediately'' implementation) vs. how many connections to the proxy get held open at once. If you have a lot of chat clients, you might want to back off the rate at which the JS clients re-poll after a timeout. Hope that makes sense, I''m too tired to explain it better ;-) L. On 15-Sep-05, at 10:33 PM, Richard Livsey wrote: > You can''t do XML socket connections with XmlHttpRequests. Although > your original post doesn''t make this clear, it looks like you > understand this fine. > > You will not be able to just replace the java client, as you can''t > write a client app to interface with the socket server purely in > javascript. So you will have a proxy app which will open a socket > to the server and do all that communication in the background, > buffering messages ready for the JS client to grab them. Then you > will have to poll that proxy app at intervals with javascript to > get/send the messages in the chat. > > I did something like this as a proof of concept for a system a > while back and found that continuous polling didn''t work very well > due to the nature of conversations: > > Long periods of silence followed by periods of active conversation. > > To make it responsive you end up with a short polling interval, but > this is then very wasteful when there''s not much going on in the room. > > Ideally, you want to poll the server only when there is a message > to receive, obviously this is not possible without a socket > connection! > > To this ends I wrote a ''decaying poll'' [1] in javascript a while > back which you may or may not find useful. This was prior to > Prototype etc... so I could probably do with revisiting it to > integrate it in at some point if anyone thinks it could be useful > in there? > > This allows you to poll the server and if there are no messages to > wait longer till the next poll. So you could start off polling > every second and gradually decay down to a 5 to 10 second poll when > there is periods of quiet. Once a message is received, then you > reset the poll. Basically the opposite of the TCP slow start > algorithm. It''s fast start instead. > > In this way, periods of active conversation are polled regularly to > cut down on lag, but periods of silence have little polling and > thus cuts down on resources - both server and client. > > This approach worked very well and seemed to fit the conversational > model quite nicely. > > In adition to this polling, we wrote a socket client in Flash which > sits on the same page as the chat. If the user has flash enabled > then we don''t poll at all and the Flash script tells the javascript > when there is a message waiting. In this way the JS only asks for > content when there is some waiting. If the user doesn''t have flash, > it falls back on the decaying poll. > > That ended up being a bit longer than planned, but hope some of > that helps! > > [1] http://livsey.org/2005/06/07/decaying-poll-in-javascript/ > > -- > R.Livsey > http://livsey.org > > > > Stephen Major wrote: > > >> Let me re-phrase my last post, >> >> I think you mis-understand what I am asking about, I am not asking >> to use >> the technology to actually do the connecting, I am talking about a >> client >> interface that utilizes ajax for refreshless chat client, with a >> backend on >> the server that handles the calls. Whether it be php or whatever, >> I want to >> see other peoples input in how they would go about it, before I >> jump head >> first into a new project. >> >> -----Original Message----- >> From: rails-spinoffs-bounces@lists.rubyonrails.org >> [mailto: rails-spinoffs-bounces@lists.rubyonrails.org <mailto:rails-spinoffs-bounces@lists.rubyonrails.org> ] On Behalf Of >> Thomas >> Fuchs >> Sent: Thursday, September 15, 2005 2:30 PM >> To: rails-spinoffs@lists.rubyonrails.org >> Subject: Re: [Rails-spinoffs] Ajax to sockets. >> >> Sorry, but you don''t know what you''re talking about. >> >> "XMLHTTP is a set of APIs that can be used by JavaScript, JScript, >> VBScript >> and other web browser scripting languages to transfer XML or other >> data to >> and from a web server using HTTP."[1] >> >> So, it''s the HTTP protocol only (and for security reasons, only >> with the >> originating web server). >> >> Thomas >> >> [1] http://en.wikipedia.org/wiki/XMLHttpRequest >> >> Am 15.09.2005 um 22:48 schrieb Stephen Major: >> >> >> >>> Buddy unless you have something intelligent to offer to the >>> disussion please do not reply, >>> >>> You obviously do not know what you are talking about, or b you >>> are so closed minded in the subject that you do not think outside >>> the box, AJAX is used for client side scripts to call procedures >>> to server side scripts, this could be done by calling php >>> functions that handle the socket connect. >>> Utlizing ajax to properly form the xml, being that the the socket >>> server is a xml socket server, would seem like a good way to >>> handle the client without a refresh like current php chat clients >>> that refresh and tag a database server. >>> >>> >> >> _______________________________________________ >> Rails-spinoffs mailing list >> Rails-spinoffs@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >> >> _______________________________________________ >> Rails-spinoffs mailing list >> Rails-spinoffs@lists.rubyonrails.org >> http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs >> >> >> >> >> > _______________________________________________ > Rails-spinoffs mailing list > Rails-spinoffs@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs > -- Laurie Harper Open Source advocate, Java geek: http://www.holoweb.net/laurie Founder, Zotech Software: http://www.zotechsoftware.com/ _______________________________________________ Rails-spinoffs mailing list Rails-spinoffs@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs <http://lists.rubyonrails.org/mailman/listinfo/rails-spinoffs>
Hi all, Let me present my approach to socket connections by AJAX and server push. At the moment the implementation of the concept is broken, because it is in VERY early development. But in a feq days I will upload it. Site loads througs Rails on Apache Apache runs with mod_proxy. Site does ajax post to page /ajaxpush/ Mod_proxy forwards this request to a small ruby webserver that I have written. This server keeps the connection open endlessly and uses chunked encoding to send data to all listening clients The rails setup can use a socket connection to send data to the ajax server, which pushes it to all listening clients Problem: mod_proxy does buffering, so all messages have to be padded to a length of (i think) 512 byte. Maybe a squid proxy would work better, but mod_proxy seems to be less struggle to set up I will post my ruby server as soon as it is finished. Atr the moment i am hacking the webrick server to connect to the ajax server, then rails can do AJAX push. Cool! Greetings, Martin __________________________________________________________________________ Erweitern Sie FreeMail zu einem noch leistungsst?rkeren E-Mail-Postfach! Mehr Infos unter http://freemail.web.de/home/landingpad/?mc=021131