[squeak-dev] HydraStream implementation , pull or push scheme?

Hi all,

there is two ways how to reliable communication can be implemented
over non-reliable one.
(maybe there is much more, but lets consider following ones).

The push scheme is:

when user writes to stream, stream collects data in small cache, and
when cache is full or user flushes stream, it sends packet immediately
to remote side. As variant, stream can flush itself periodically (each
5 ms or so) to not make receiving side starving if user sending small
amounts of data, not enough to fill write cache.
A receiving side tracking a sequence of packets arrived, and if
sequence breaks, due to some packet lost, then it sends request to
resend all packets from last valid sequence number.
So, a sending stream should keep data sent lately, until remote side
will confirm that it received it and resend packets in case if some
data was lost.

The pull scheme is:

when user writes to stream, stream is just collecting a data. Flushing
stream not causing data  being sent. A sender may block when it's
cache is full, and will unblock only when receiving side will confirm
that it's received packets, which now can be discarded from write
cache buffer.
Data is sent only when remote side places request on receiving next packet.
So, when user calls #read, a receiving side sends 'request next data
packet #N' and when it's received, returns from method.

Both schemes having own cos and pros, and is mainly about which
operation takes preference: reading or writing.

Or, maybe i should think to add options to let user choose which scheme to use?
So,
Side A, can choose which scheme to use for writing (and notify Side B about it),
as well as Side B, can choose which scheme to use for writing.

--
Best regards,
Igor Stasenko AKA sig.

> when user writes to stream, stream is just collecting a data. Flushing
> stream not causing data  being sent. A sender may block when it's
> cache is full, and will unblock only when receiving side will confirm
> that it's received packets, which now can be discarded from write
> cache buffer.
> Data is sent only when remote side places request on receiving next packet.
> So, when user calls #read, a receiving side sends 'request next data
> packet #N' and when it's received, returns from method.

Pull is usually much better.

I used push for GNU Smalltalk's TCP sockets and in retrospect it was not
a great idea).

Paolo

On 25.02.2008 15:31, Paolo Bonzini wrote:
>
>> when user writes to stream, stream is just collecting a data. Flushing
>> stream not causing data  being sent. A sender may block when it's
>> cache is full, and will unblock only when receiving side will confirm
>> that it's received packets, which now can be discarded from write
>> cache buffer.
>> Data is sent only when remote side places request on receiving next
>> packet.

>> So, when user calls #read, a receiving side sends 'request next data
>> packet #N' and when it's received, returns from method.
>
> Pull is usually much better.

Why?
What if the user does not await data, but there may be some some time (asynchronous communication)?

>
> I used push for GNU Smalltalk's TCP sockets and in retrospect it was not
> a great idea).

What have been the problems?


Regards,
Stephan

>
> Paolo
>
>

--
Stephan Rudlof ([hidden email])
   "Genius doesn't work on an assembly line basis.
    You can't simply say, 'Today I will be brilliant.'"
    -- Kirk, "The Ultimate Computer", stardate 4731.3