[Twisted-Python] Need words of wisdom regarding PB
Paul G
paul-lists at perforge.com
Thu Jun 29 18:15:45 MDT 2006
chaz,
quick note: please don't top post (in replies to me, anyway). just common
courtesy.
in my context, the solution was meant as a synchronization method with some
application-level logic to be used instead of rsync (i didn't need
differencing and needed some complicated candidacy logic). the pb client
simply opened multiple connections and sent data chunks labelled with chunk
id and object id, multiplexed over the connection pool, with the chunks
being pulled out of a queue that a threadpool reading from disk and
optionally gzipping data was writing to. i didn't need to write logic to
grow the connection pool to maximize bandwidth (i easily saturated a
fast-e), but that would be trivial.
note: i do not advocate doing this unless there is a very good reason
existing tools won't work for your application. reinventing the wheel makes
baby jesus cry.
-p
----- Original Message -----
From: "Chaz." <eprparadocs at gmail.com>
To: "Paul G" <paul-lists at perforge.com>
Cc: "Twisted general discussion" <twisted-python at twistedmatrix.com>
Sent: Wednesday, June 28, 2006 8:03 AM
Subject: Re: [Twisted-Python] Need words of wisdom regarding PB
> Paul,
>
> Thanks for the information. I hadn't thought about multiple pb
> connections, but I might even for my low-latency environment. I can have
> files that range from very small to very very large and getting them
> transferred in a reasonable period of time might might require many
> connections at once.
>
> In your solution did you just allow the client to "divide" up the work
> or was there something else you did?
>
> Chaz
>
> Paul G wrote:
>>
>> ----- Original Message ----- From: "Chaz." <eprparadocs at gmail.com>
>> To: "Twisted general discussion" <twisted-python at twistedmatrix.com>
>> Sent: Sunday, June 25, 2006 2:20 PM
>> Subject: [Twisted-Python] Need words of wisdom regarding PB
>>
>>
>>> I have a problem to solve: I need to get files from one machine to
>>> another. I had thought about all the obvious solutions (and implemented
>>> some of them); for instance adding an FTP server to my Twisted services
>>> and using a client. I thought about doing the file transfer with XML-RPC
>>> and even SOAP. And I even thought of WebDav.
>>>
>>> I started reading about PB and thought it might be useful. I thought
>>> about building a "remote" class that simulates open and all its
>>> functions, like read, write, close, etc.
>>>
>>> The more I thought about it the more I thought it cool and the way to do
>>> it. That got me thinking that I must be missing something. I am curious
>>> about what you might think of this approach. Is there another better
>>> way?
>>
>> i implemented file transfer with an optional intermediate gzip stage
>> using pb a long while ago. if you're dealing with fairly low latency, a
>> single pb connection is fine; for higher latencies, you'll want to
>> multiplex multiple pb connections (this has to do with tcp, not pb).
>> with my quick hack, i was able to saturate a fast-e with virtually no
>> significant cpu utilization - the disk io and the network were the
>> bottlenecks.
>>
>> -p
>>
>
More information about the Twisted-Python
mailing list