Re: [Fresco-devel] [ReFresco 03] Proposed network architecture overview

This is a MIME-formatted message.  If you see this text it means that your
E-mail software does not support MIME-formatted messages.

--=_heaven-32327-1075637445-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Nathaniel Smith <[email protected]> wrote:
> Current packet layout in my prototype is as follows:
>    1 octet: packet type identifier
>       (Currently this is one of MESSAGE, MESSAGE_FRAGMENT,
>        MESSAGE_FRAGMENT_END)
>    5 octets: packet length
<snip>
> ... sender ... reply-to ... fragment stream field

Let me do the following assumptions:

  * connections will not loose messages in transit and messages will
    arrive in the same order that they were send down one connection.

    TCP, pipes etc. should fullfill this requirement

  * Objects will process messages in the order they receive them

Then I'd propose the following header for messages:

   2 octects message flags:
      first flag: meaning MESSAGE or REPLY

        This flag is needed so the receiver may figure out whether to
        send this on to an object initiating a new method call (once
        marshalling is doen) or whether this needs to get added to the
        result queue.

      second flag: meaning FRAGMANT_PART or FRAGMENT_END

        An unfragmented message will be marked "FRAGMENT_END" to signal
        that the receiver can immediently pass on the massage and does
        not need to wait on follow up messages.

      third flag: meaning NO_ERROR or ERROR

        We do need a way to signal "object not found" and similar
        occurances at the message passing level. We can not say we will
        handle this at the marchalling level (which will need its own
        error handling).

      Rest reserved for future use.

   2 octets message length (including header)

      For practical reasons I suggest not having huge messages: One object
      could DOS a connection by sending one huge package without other
      objects having the chance of getting anything across the same wire.

      Of course both client and server need to be able to fragment messages
      under this size constraint.

  16 octets recpient

  16 octets reply-to

     I put this last since we might want to leave this out at some
     point, adding a flag to specify that the reply-to is gone missing;-)

     And the recipient is needed first anyway.=20

A fragment stream field is not necessary: Under the assumptions made above
the packages arrive in order. One object will of course not sprinckle other
communication inbetween one message it is sending, so there's no danger of
a mix up there either.

> > I still fail to see why we don't need sequence numbers. Is the cap thro=
wn
> > away after receiving a single message?

Well, I do so now after having slept a night over ewalnut;-) I think I'm
slowly getting into this;-)

> I suspect that often a cap will be thrown away after receiving a
> single message, yes.

I don't think that's necessary under the assumptions I made above.

Let's assume Alice sends Bob two messages, expecting a reply for both of th=
em.
Bob gets to work on those in the order he received them (and under the
assumptions made above that's the order in which Alice made them, maybe with
some of Clive's and Dave's requests thrown in between which does not matter=
 here).
Bob finishes the first one, sending a message marked REPLY back to Alice. S=
he
knows that this must be the answer for her first request.

Then Bob does some work for Clive and must get some information from Alice =
for
that: He send a message marked "MESSAGE" to Alice requesting that info. Ali=
ce
will not mix that one up with the expected reply due to the missing REPLY-f=
lag.

Alice replies, Bob finishes his work for Clive and replies to him, Bob star=
ts
to work on the second request for Alice and sends his next reply, all works=
 out.

Let's assume Bob is funny and send an unrequested third reply: Alice does n=
ot wait
for one and will just throw it out.

Of cource Alice could get a new Cap for each request and throw that away af=
ter
each reply, thus making sure Bob can not be funny, but in a "trusted" local
case this seems extremly wasteful to me.

--=20
Gruss,
Tobias

------------------------------------------------------------
Tobias Hunger           The box said: 'Windows 95 or better'
[email protected]                      So I installed Linux.
------------------------------------------------------------

--=_heaven-32327-1075637445-0001-2
Content-Type: application/pgp-signature; name="signature.asc"
Content-Transfer-Encoding: 7bit
Content-Description: Digital signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFAHPj/v0FZW3NyoqURAjiZAKCZoEMdPoQdmN/k3/cEEBEGAu0x7gCbBIqH
kcqmYB13Ukxxmhyiw5fqtwE=
=+EWJ
-----END PGP SIGNATURE-----

--=_heaven-32327-1075637445-0001-2--