Re: p2p parrarel/ cluster computing.

[Sean Conner <sean@...>]

It was thus said that the Great Sam Bavi once stated:
> Thank you for that thorough answer, really appreciated =)) So basically
> loosely speaking the pull mvc is much like in ftp where I choose to tell
> model Im ready now present me with new data. What Is a p2p torrent
> application considered where the relationship between the view and the
> model is much more of a blur? 

  I can't answer that as I've never used Bit Torrent, nor have I even looked
at Bit Torrent.  I also found it a bit surprising you mentioned MVC as it
doesn't really fit here (it's was originally intended for user interfaces
and is a staple of the object-oriented crowd, of which I'm not one).

> Its a interesting choice which I haven’t
> been thinking about,  on one hand push leaves less room for idle clients
> and so on but Is more careless with the data, logically pull creates a
> more sensible flow of data but leaves more room for time wast because Its
> up to the client to check in, something like that? 

  With push, you need to inform the server of all clients, and its up to the
server to keep them busy.  I have a job, which client is free for the work? 
This one ... oh, it's down.  I need to check another one ... and so on.  For
your render farm, it's easier to implement the pull method, where each
client asks the server for a job (or jobs, depending upon the amount of work
it can do and the client has more information about what its capable of than
trying to keep the server up to date with such information).

  You can think of pull vs push also as polling vs interrupts.  If work (or
events) are spradic, it makes more sense to interrupt (or push); but if the
work (or events) are constant, then polling (or pulling) is better as there
usually is something always available and you can avoid the overhead of
interrupts (or pushing).  

  Which you use really depends upon the frequency of work, as well as the
workload of each job.  In rendering, there's a large frequency of work, each
of which takes time; in that case, having the clients pull for jobs makes
the distribution of jobs easier (you can always add more clients).

> Based on your suggestions I will check out torch-ipc tomorrow and se where
> It goes, https://github.com/twitter/torch-ipc. From what I’ve read It
> looks very promising. Again Thanks for taking your time and have a good
> night =)) Regards

  From a quick look, torch-ipc just seems like yet another IPC mechanism,
like ZeroMQ.  Whatever works I guess.

  -spc