> On 19 May 2016, at 10:40, Sven Van Caekenberghe <s...@stfx.eu> wrote:
>
> Hi Holger,
Dear Sven,
> However, you need a regular opportunity to send something out. Thinking out
> loud, what about something like
>
> StampClient>>#runWith: receiveBlock do: sendBlock
>
> where receiveBlock is like it is now, and sendBlock is called regularly,
> basically when the loop goes through another cycle, to give you the
> opportunity to send something, being sure to have exclusive access.
>
> In the sendBlock you could query your sharedQueue that is being filled by
> another process, properly MP safe.
>
> The invocation of #runWith:do: should of course be forked.
>
> Does that make sense ?
It makes sense for my unacknowledged SEND but I see several issues for a
general scheme:
a.) If write / receive ratio is not equal and I block in the send then I will
not receive quickly enough. And if we block on receive (with the *TimedOut) we
will not write enough. This is one general architecture issue I seem to circle
around[1]. I should not have block one or the other.
b.) Integration with ACKed sends (putting a receipt, reading a receipt-id). Is
there a generic way to handle it? E.g. I would keep an event in the SharedQueue
until it has been acked (and detect timeouts or such).
Last but not least. How do you handle the ConnectionClosed and do the
re-connect? It seems that >>#runWith: will exit iff ConnectionClosed signal has
been raised. Will you respawn the process? Will you create another StampClient
and re-execute?
sorry, more these are more questions than answers. I have a local client that
is similar to >>#runWith:do: (but calls receive from within the send routine).
kind regards
holger
[1] With POSIX/C there is select(), in Windows WaitForMultipleObjects and maybe
with erlang the selective receive. Now it is not very object orientated but in
pseudo erlang syntax.
receive
FrameReady -> self handleFrame: arg;
FrameToSend -> self writeEvent: arg;
Disconnect -> self reconnect.
...
after
self timeout -> self checkRecvHeartbeatOrSendIt
end
I could emulate it by spawning multiple processes on "receive", creating a
queue, having a semaphore.. but I don't know if I want to limit it to sockets...
