Re: Message Pushing and TCP Transport

[Daniel Manley <dmanley@tucows.com>]

> 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. 

If you're using poll to ping a connection to keep it alive, then you're 
already doing it anyhow.  So I don't think there's a negative benefit. 
 Pushing pushes the substantial overhead *multiplied* by each registrar 
client to the server, who's already overworked anyway.

> 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. 

But I might want the message to go to voice mail if I'm too busy, and 
I'll get it later when it's convenient for me.

>
>
> THAT is why push is better than pull, for some scenarios.
>
>
> At 10:04 PM 8/20/2001, Peter Chow wrote:
>
>> I was at the Provreg meeting and there was at least one
>> implementor who was concerned with the extra complexity
>> introduced by the push mechanism.
>
>
> Added features ALWAYS means added complexity, so there is nothing 
> special about someone being concerned about complexity.
>
> The focus needs to be on the question of added benefit.  Is there 
> enough benefit?
>
> For simple, low-volume registration scenarios, no doubt a simplistic 
> protocol is preferred.
>
> If provreg is trying to produce a protocol that can support 
> high-volume transactions, it needs to use modern transaction 
> technology models.
>
> d/
>
>
> ----------
> Dave Crocker  <mailto:dcrocker@brandenburg.com>
> Brandenburg InternetWorking  <http://www.brandenburg.com>
> tel +1.408.246.8253;  fax +1.408.273.6464
>