Re: [GSTP-devel] thoughts about the specification

[Daniel R. <no...@me...>]

m=E5n 2002-11-04 klockan 10.38 skrev Alexander Hav=E4ng:
> > Of course sendfile() isn't portable, but the general idea of
> > zero-copy-networking is. I find it hard to believe that any
> > implementation of zero copy networking on any platform will include the
> > ability to files and then return the control to userspace every 32k, bu=
t
> > you never know.
>=20
> Why not?
> ssize_t  sendfile(int  out_fd,  int  in_fd, off_t *offset, size_t
> count);

I think I missed 'efficiently', but it doesn't matter. I'm no big expert
on low level performance, I just mentioned it as something to think
about.

> I don't think we'll be seeing any TLS code in the kernels any time soon
> though :)

True.

> > Perhaps one could add an operation "get" that would be the one roundtri=
p
> > equivalent for "open; read; close". After having worked a bit with
> > networking in GPRS environments (read: lousy latencies) i know that
> > having the ability to cut down on roundtrips is a good thing.
>=20
> I see your point.. and we'll keep this open. I don't want to introduce
> any new commands for doing the same thing, but I will consider adding a
> new option for OPEN that tells the server to start sending data right
> away, as well as closing it on EOF.
>=20

more opcodes, or options to open, that doesn't matter to me. I think
that from a documentation point of view an option that changes semantics
so drastically would be less well structured than having a separate
opcode, but that's just personal taste.

> > I believe that mixing in personal tastes like this one in fundamental
> > protocol decisions will possibly prevent the protocol from being widely
> > used.
>=20
> One of the problems with say, the FTP protocol, is that is to
> overdeveloped. Only god knows all the features in FTP, and there are
> millions of ways of doing things.
> Just look at all the different PORT and PASV commands used today.
> Some use PORT, others EPORT, or LPORT, or ZPORT..=20
> I guess what I'm saying is that there should be one way of doing things,
> and only one.
>=20

True. The problem with ftp is that it is badly engineered, and that is a
different thing from saying "we should have the overhead of TLS
everywhere because I dislike unencrypted network traffic in my network
monitoring program"

> Nothing stands in the way of changing the underlying transport layer of
> GSTP from TLS to plain TCP-data, other than me thinking it will fork()
> things where no forking is necessary.

I don't see what this has to do with fork(2). Perhaps you mean two
different code-paths when only one is necessary.

> After all, when downloading a file that takes 5 minutes to download,
> what does it matter that it takes another second or so at the worst to
> negotiate a TLS connection?
>=20
> When downloading 500 files, it's still only done once, compared to 500
> TCP handshakes with FTP.
>=20

I was thinking more from the server's point of view.

A scenario: when Microsoft switches to GSTP to transfer their security
updates for their operating system in 2005 there are ~100 million
Internet connected windows computers that automatically downloads a 28k
file from their server approximately at the same time. For one 28k file
i would approximate that perhaps 10% of the cpu for sending the file
would go into TLS negotiation, and perhaps perhaps 50% for doing the
encryption (if a weak crypto is chosen).

If they could instead use non-encrypted transport for their service they
could send exactly the same bits over wire to all the different clients,
and save a considerable percentage of the cpu time on the servers.

This of course assumes a highly efficient GSTP implementation, but that
is no reason to limit the theoretical maximum performance at protocol
level (by mandating TLS).

> If the need should arise for an even more lightweight GSTP protocol for
> handheld-devices or slow links, then we'll call it "diet GSTP" and stick
> a green keyhole on it.

Developing a different protocol "variant" just because we didn't bother
to do it efficiently the first time seems like the FTP way of developing
standards :P
=20
> > Don't you see anonymous downloads (when no user authentication what so
> > ever takes place) as a significant use case of GSTP? I find that
> > strange.
>=20
> Of course I do, in due time.
> Anonymous logins either don't issue a AUTH command, or use the standard
> FTP way with "anonymous/ftp" + "emailaddress".
> This should be in the protocol description, but it's not :)

oh. that's good :) I would suggest that an option in the auth command
packet indicated that the client is interested in anonymous login,
instead of using a special "magic" username that means "this is not
really a username". Using no AUTH command would make error messages more
difficult to understand. open(fil.txt) would fail with "anoymous access
denied / permission denied" or something like that.


> Also.. the Internet is a fast moving but extremely slow changing place..
> FTP will not die quietly :)
> GSTP is a slow moving project.. so we have time to make it right :)
>=20
> The server is getting more and more stable each day, I'll run some evil
> tests with 10000 users across gigabit ethernet or loopback and see if we
> can handle the load. I don't think it will be a problem.
>=20

Sounds interesting :)

/noa