Re: smart upload server
>> Is the protocol stateless? How does the client reference the
>> changes file in the second and later requests?
> Stateless if possible, with some time window for each changes file,
> checksums are on server so he knows what should come.
Server and client should also in some way exchange protocol versions
they know/support. Their api/abi/whateveritsnamed, so later changes can
be added easily without breaking existing software, client/server would
know the other side cant handle newfeature and wouldnt use/advertise it.
>> Two other features that will be implemented later but may influence
>> the protocol's definition: How will delayed uploads be handled by the
>> protocol? How about dcut like commands files
>> (ftp://ftp.upload.debian.org/pub/UploadQueue/README)?
> There should be command requests, by them you can control it like with
> command
> files.
> Something like:
> client > server: COMMAND + command (format like in file?)
> server > client: OK or ERROR with some message
For commands we want them signed. Current commands file specification is
at ftp://ftp-master.debian.org/pub/UploadQueue/README, though the actual
commands we use might be different. Important part is the signature.
Also, some things, random wishlist, for the app:
- daemonized, of course. React to signals sent with kill(1), like for
example
"USR1" -> Graceful shutdown. First close listeners. But finish
transfers you are currently receiving. Then shutdown app.
"HUP" -> reread config.
- proper logging.
--
bye, Joerg
Lisa, if the Bible has taught us nothing else, and it hasn't, it's that
girls should stick to girls sports, such as hot oil wrestling and foxy
boxing and such and such.
Reply to: