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-1914-1075724529-0001-2
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Nathaniel Smith <[email protected]> wrote:
> > Let me do the following assumptions:
> >=20
> >   * connections will not loose messages in transit and messages will
> >     arrive in the same order that they were send down one connection.
<snip>
> Yes, we definitely assume this.

Wow, we do agree on something right on the first try! ;-)

> >   * Objects will process messages in the order they receive them
>=20
> I would say rather that objects will receive messages in the order
> they were sent,

Yeap, that's what I meant too.

<snip>

> > Then I'd propose the following header for messages:

Aehm... make that packets, not messages! Sorry, I got confused by the
fragmentation flag in the message... Why do you have that by the way?
With 5byte message length field you shouldn't get into trouble there
anytime soon.

> >    2 octects message flags:
> >       first flag: meaning MESSAGE or REPLY
>=20
> I don't understand what this paragraph means.  Perhaps you could
> expand a bit on your assumptions re: the difference between messages
> and replies?  Like, what's a "result queue"?  And why shouldn't reply
> delivery be via a method call?  (In an asynchronous world, replies
> always come as callbacks in one way or another...)

Having sleapt another night over ths problem: You are right. This
flag is not necessary.

> Not sure why you want to distinguish these cases.  I've been imagining=20
<snip>=20
> >       second flag: meaning FRAGMANT_PART or FRAGMENT_END
>=20
> Doesn't work, because as explained below, fragment packets do need a
> "fragment stream" identifier;
<snip>

I am beginning to suspect that you are right here too, but I'm not sure
yet.

> >       third flag: meaning NO_ERROR or ERROR
<snip>
> I've been going back and forth in my own mind whether marking some
> messages as errors makes sense.
<snip>
> One way or another, here, we have to break
> the nice boundary between the messaging protocol and the marshalling
> protocol.

I'd rather not do that... I'd definitly prefer a clean and simple
message passing system (that you can use without the marshaling stuff
if you must) with a clean and simple marshaling protocol on top. I like
layers;-)

> The issues are sufficiently murky that I think we should wait until
> we've had a chance to experiment with things more before picking a
> solution.

I'm definitly fine with that.

>  Right now it's not obvious to me if there are any errors
> to report besides "object not found",

"Connection lost", "Illegal fragment/packet", "Out of memory"
(message is too long), ...

<snip>
> >    2 octets message length (including header)
<snip>
> No, this section has problems.

You are right: I meant packet length, not message length. The message is of
corse the sum of the packetsizes minus their headers. I don't see a need
to pass that along though.

<snip>
> Your DOS scenario isn't a problem either.

I still think it is: Lets assume there are two object A and B in the same
client. They share one connection to the server. A can now block that
connection for long times by sending huge messages (the max. message length
takes several days to go over a 100MBit network). B can't send data to the
server during that time.

You argue that this is not an issue as it is the client's responsibility
to look after its own latencys... I see that differently.

<snip>
> > A fragment stream field is not necessary: Under the assumptions made ab=
ove
> > the packages arrive in order. One object will of course not sprinckle o=
ther
> > communication inbetween one message it is sending, so there's no danger=
 of
> > a mix up there either.
>=20
> No, this is wrong.  Say we have
>=20
>    A --\
>         Server --- C
>    B --/
>=20
> A and B both start sending long messages to C.
<snip>
> So as soon as the server is unwilling to buffer any more,
> it starts fragmenting the messages from A and B, and sending the
> fragments to C.  These fragments will arrive intermixed.

=2E.. which is not a problem as long as they were send by two separate
originators. That's basically a stream number... of course this is
assuming that a originator will be set, even on asynchronous messages
which is not the case with the architecture you are proposiing. Mine
is different in that respect.

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

Of course it is! I got it now!

--=20
Gruss,
Tobias

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

--=_heaven-1914-1075724529-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)

iD8DBQFAHk0iv0FZW3NyoqURAr1FAJ49Qf+5DlG12uwLCGbpR9sBEeBNewCeJjgE
SmiPdM+K3c5TfpVjx+eW6RU=
=C1pC
-----END PGP SIGNATURE-----

--=_heaven-1914-1075724529-0001-2--