Why do chat software poll continuously instead of respoding to events?

[John Dalberg]

I am looking for an asp.net based chat software. I have looked at some
(asp.net and php based) and they consist usually of a javascript piece
where the web user (visitor) initiates a chat from a web page, an operator
client which is usually a desktop app or browser based and the server part
which serves as a controller between the operator and visitor, sending and
receiving the chat text between them.

What I have noticed is that the operator keeps polling the server to find
out if a visitor started a chat request, every 2-3 seconds. I find this
continuous traffic unnecessary. Why aren't chat software designed so that
the visitor Javascript code send a web service to the server which raises
an event to the operator's machine notifying them of chat request (push
method) instead of the operator doing continuous polls? I would think
network guys or software traffic monitors and such would take notice of
this continuous traffic.

Are there chat software that do push's when needed instead of continuous
pull's? I would like to use one.

John Dalberg

[bruce barker]

you would need a custom webserver to keep a network pipe open (asp.net
would not hold up much over a couple hundred users, and woudl need
special config to do this). google does this with teir chat, but they
have modified web servers that can keeps thousands of connections open.

the standard trick if your webserver and firewall and handle it, is to
run a script in an iframe (the server pushes javascript events). every
couple of minutes you close the iframe and reopen to free memory and
reallocate server resources if necessary.

another issue is the users proxy may be limited to the number of
connections it can hold open. if your site exceeds that, it may be blocked.

-- bruce (sqlwork.com)

John Dalberg wrote:

I am looking for an asp.net based chat software. I have looked at some
(asp.net and php based) and they consist usually of a javascript piece
where the web user (visitor) initiates a chat from a web page, an operator
client which is usually a desktop app or browser based and the server part
which serves as a controller between the operator and visitor, sending and
receiving the chat text between them.

What I have noticed is that the operator keeps polling the server to find
out if a visitor started a chat request, every 2-3 seconds. I find this
continuous traffic unnecessary. Why aren't chat software designed so that
the visitor Javascript code send a web service to the server which raises
an event to the operator's machine notifying them of chat request (push
method) instead of the operator doing continuous polls? I would think
network guys or software traffic monitors and such would take notice of
this continuous traffic.

Are there chat software that do push's when needed instead of continuous
pull's? I would like to use one.

John Dalberg

[Steve C. Orr [MCSD, MVP, CSM, ASP Insider]]

HTTP doesn't support a server raising an event to a web browser. You'd need
to implement a more sophisticated networking protocol, such as TCP/IP.
That's not easy to do in a web browser.

--
I hope this helps,
Steve C. Orr,
MCSD, MVP, CSM, ASPInsider
http://SteveOrr.net
http://iPhonePlaza.net
"John Dalberg" <no****@nospam.ssswrote in message
news:20*******************@newsreader.com...

>I am looking for an asp.net based chat software. I have looked at some
(asp.net and php based) and they consist usually of a javascript piece
where the web user (visitor) initiates a chat from a web page, an
operator
client which is usually a desktop app or browser based and the server
part
which serves as a controller between the operator and visitor, sending and
receiving the chat text between them.

What I have noticed is that the operator keeps polling the server to find
out if a visitor started a chat request, every 2-3 seconds. I find this
continuous traffic unnecessary. Why aren't chat software designed so that
the visitor Javascript code send a web service to the server which raises
an event to the operator's machine notifying them of chat request (push
method) instead of the operator doing continuous polls? I would think
network guys or software traffic monitors and such would take notice of
this continuous traffic.

Are there chat software that do push's when needed instead of continuous
pull's? I would like to use one.

John Dalberg

[Abdu]

On Jul 2, 1:36*pm, "Steve C. Orr [MCSD, MVP, CSM, ASP Insider]"
<[e-mail]:

HTTP doesn't support a server raising an event to a web browser. *You'dneed
to implement a more sophisticated networking protocol, such as TCP/IP.
That's not easy to do in a web browser.

--
I hope this helps,
Steve C. Orr,
MCSD, MVP, CSM, ASPInsiderhttp://SteveOrr.nethttp://iPhonePlaza.net

"John Dalberg" <[e-mail] in message

news:20*******************@newsreader.com...

I am looking for an asp.net based chat software. I have looked at some
(asp.net and php based) and they consist usually of a javascript piece
where the web user (visitor) initiates a chat from a web page, *an
operator
client which is usually *a desktop app or browser based and the server
part
which serves as a controller between the operator and visitor, sending and
receiving the chat text between them.

What I have noticed is that the operator keeps polling the server to find
out if a visitor started a chat request, every 2-3 seconds. I find this
continuous traffic unnecessary. Why aren't chat software designed so that
the visitor Javascript code send a web service to the server which raises
an event to the operator's machine notifying them of chat request (push
method) instead of the operator doing continuous polls? I would think
network guys or software traffic monitors and such would take notice of
this continuous traffic.

Are there chat software that do push's when needed instead of continuous
pull's? I would like to use one.

John Dalberg

The operator client doesn't have to be web based client, just the web
visitor. The web visitor requests a chat. The chat request goes to the
web server through normal hhtp and the web server then talks with the
operator client (should be desktop app) through .net remoting, wcf or
whatever. Most of the chat apps I have seen have the operator client
be web based. It doesn't need to be. This forces the operator client
to poll the web server and see if there's chat request. The only
reason I can think of is firewalls at companies which usually do not
allow initiating incoming requests. Any ideas on workarounds for this
scenario?
John Dalberg