RE: Message Pushing and TCP Transport

["Hollenbeck, Scott" <shollenbeck@verisign.com>]

> -----Original Message-----
> From: Dave Crocker [mailto:dcrocker@brandenburg.com]
> Sent: Wednesday, August 22, 2001 7:14 PM
> To: 'ietf-provreg@cafax.se'
> Subject: RE: Message Pushing and TCP Transport 
> 
> 
> At 06:44 AM 8/17/2001, Bason, Chris wrote:
> >2) What is advantageous about using a push mechanism for transfer
> >notification in our current registry/registrar model over
> >using a pull mechanism?
> 
> How can you do a pull if you do not even know there is 
> anything to pull?
> 
> The usual response is "polling" but that means constantly 
> polling, and in 
> this case constantly polling for something that is typically not 
> present.  Hence, substantial overhead, for negative benefit.
> 
> Do you like constantly checking for email, when there is 
> none?  Would you 
> not prefer that email "just arrive" when it is available?
> 
> Imagine never getting telephone calls.  Instead you have to 
> call a number, 
> to see whether there is anyone waiting to talk with you.
> 
> THAT is why push is better than pull, for some scenarios.

There's no need to poll constantly to determine if messages are queued for
delivery because the protocol currently provides a notification mechanism
that is carried on other common responses to let the client know that queued
messages are available.  It's true that a client that does absolutely
nothing else will need to execute a potentially empty poll, but in the far
more typical scenario clients _will_ know when messages are available
without having to poll fruitlessly.

<Scott/>