TPCServer and xdrlib

[Henrique Dante de Almeida]

On May 19, 10:28 am, Laszlo Nagy <gand... at shopzeus.com> wrote:
>
> I don't think that it is important. But if you are interested:
>
> - yes, the server will probably be I/O bound, not CPU bound
> - I'm have experience with thread programming, but not with twisted

 That part was just to show you that being multithreaded is not really
a requirement. The server could be single-threaded, for example.
Surely, if you are comfortable with writing a threaded server, there's
no problem with that.

>
> No. "Image binary data -> base64encode -> XML -> gzip" - looks very
> silly. It cannot be efficient. Do you have better ideas?>> BTW I do not care about the

 Okay, that would be silly. The questions above considered that you
would be sending typical unserialized objects that would be serialized
to XML, not pre-serialized binary data.

> use it. The server is different: it must be safe against external
> attacks. Maybe it was my bad English? Sorry for the misunderstanding.>  In general I

 That part was a joke. You didn't have to answer that. :-P

> I cannot predict "acceptable speed" requirements, but I can tell that
> there will be some clients downloading 100MB report files from the
> server, so I presume that I will need a progress bar. I think that I
> need to develop my own protocol for this, and probably the underlying

 Okay, so you need to wrap large binary files in some kind of message,
without pre processing them. I think developing your own protocol
using XDR is a safe bet.

> layer should use binary representation.>> Before I start re-inventing the wheel:

 If you are worried about not reinventing the wheel, there are a
couple of solutions I can think of. None of them seem to fully support
you security and session management requirements, so you should
estimate the required project/development time for them.

 - You may create a standard web application for that (with Django ?).
Binary transfers simply use HTTP and have trivial overhead. You have
to implement security and session management (cookies ?) on top of
that.

 - Subclass BaseHTTPServer to implement a stateful and secure
protocol. Again, binary transfers have trivial overhead.

 - If the goal of the project is to provide versioned file support,
you could use a dpkg/apt (or RPM?) based installation system (it uses
HTTP and FTP for file transfers). Write trivial front-ends in the
client and the server and choose a secure HTTP server.

 - Finally, if you want to create your own protocol, but don't want to
use XDR, you could to a similar thing using MIME based messages (the
first message part is a XML message that references the binary
attachments).

> It is NOT the best way. Just to tell one example: big endian / little
> endian integers. Definitely I need some encoding.

 Huh ? XDR does exactly that.

>
> (But if you are right and this is the best way, why would you avoid?)

 I would avoid packing/unpacking objects by hand.