You can subscribe to this list here.
2007 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
---|---|---|---|---|---|---|---|---|---|---|---|---|
2008 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Ryan F. <rf...@gm...> - 2008-01-06 04:00:33
|
Hi Jevgenij. I've forwarded the conversation to ripple-implementation, which I think you're subscribed to. I think the main concern for how to store the routing table is how it will be used in routing transactions. The operation that will be repeated at each hop of the path-finding process is find the distance to target(s) for each neighbour of the current node. Let's compare how this would be accomplished using both a simple hashtable dbm and a full sql relational database: DBM1 (Each key is a node's full routing table): For each neighbour, retrieve their full routing table from the dbm and get the distance to each target from that table. Sort the resulting list of neighbour-target distances. DBM2 (Each key is a single entry in a node's routing table): For each neighbour/target combo, retrieve the corresponding routing entry. Sort the results. SQL (Each row is a single entry in a node's routing table): Send a single query to the database asking for the routing entries corresponding to the distance from each neighbour to each target, sorted by distance ascending. Database returns full result set, already sorted. It seems to me that DBM1 will be significantly slower than DBM2 or SQL, which are similar algorithmically. SQL would be less logic to implement than DBM2, and probably faster due to that logic being in C rather than Python. Also, since we already use an SQL database to handle other aspects of the program, it is simpler to not require other libraries if there is no significant benefit. I'm quite sure that updating the routing table won't be significantly slower using SQL if we do it intelligently, and may even be significantly faster if we can accomplish some of the algorithm in SQL. (I can see a way to do this using the algorithm I proposed of propagating updates outwards from nodes with added/deleted edges.) If you see a smarter way of using a simple DBM for path-finding that beats SQL, let me know. Ryan On 1/5/08, Jevgenij Solovjov <js...@gm...> wrote: > Hi Ryan, > > Lately, I've been thinking about how to implement disk-stored and > RAM-cached routing table, which could be referenced using Python > dictionary syntax: > - as a dictionary of dictionaries or as a dictionary of lists; > perhaps, even as a list of lists, ultimately. > > First, I concluded that using SQLAlchemy + ORM + Postgres here is an > overkill: SQL statement formation, sending over TCP/IP and further SQL > parsing is absolutely unnecessary. > > The second conclusion, promptly after that, was: "implementing this > myself is reinvention of wheel, actually; and, since it'll be in > Python, it'll be much slower than existing solutions.". First, I took > a look at Berkeley DB, which has python "bsddb" interface. It looks > ideal from technical side - it even supports DB partitioning, in case > Ripple-Trader's popularity grows ultrafast ;) . Its open license is > "strong copyleft" though, and does not suit us if we want keep code > closed for a while. The commercial license does not feel like a sane > option, since Berkeley DB is owned by Oracle. > > So, my intention is to instead use "gdbm" accompanied by "pickle" > serialization. Do you think I am on the right track? > > > Jevgenij > > PS. I've corrected and properly (hope so) documented my "rmanager.py" > module; then, reworked it to use sets instead of lists. Will commit it > to SVN in a couple days - as soon as I get normal non-proxied Internet > connection. > |
From: Kasper S. <kas...@gm...> - 2007-04-12 09:04:00
|
Thanks for the fast response. I'm subscribed to this list now. > (There's also a ripple p2p implementation that I'm working on that > will eventually merge with ripplesite's front end and replace its > local payment and routing with distributed versions. I'm developing > that much more actively at the moment. Let me know if you'd prefer to > help with that. I'm using twisted for networking and sqlalchemy as an > ORM.) I want to help with whatever I can help with. It usually works best when I have something running so that I can dive right into it. Is rip2ple somewhere in svn? :) > I see that Django has released version 0.96, which looks very > compatible with 0.95 code, so we should probably be using that. Ok. I had already grabbed 0.91, but I'm not getting anywhere with either MySQL, postgres or sqlite3... Doesn't work very well with cygwin. I might boot my Debian, but this cheap laptop's hardware (wifi+gfx) are not very well supported. > I also have a trac instance that I used awhile back that I can and > will revamp for ripplesite development. I heard good things about trac. > William Waites has made a start incorporating django transactions into > the code (see the 'Ripplepay + Dialstation' thread of rippleusers for > code attachments), but reports that it isn't working yet. Ok. I'll take a look. bye, Kasper |
From: Ryan F. <rf...@gm...> - 2007-04-11 18:32:03
|
I've cleaned up my old trac instance: http://trac.ripplepay.com/ This is probably a good spot to organize ripplesite development. All my old ripplepay tickets are still there lying around. I think most of them still apply. I'll go through and clean them up as I have time. I should probably also include ripplep2p as a svn branch/trac component since it will merge with ripplesite eventually... Does this make sense to anyone? Anyone who wants a trac/svn login so they can make changes/commits please email me with desired user/pass if any. Ryan |
From: Ryan F. <rf...@gm...> - 2007-04-11 17:11:08
|
Hi Kasper. That's awesome that you can help out! I'm cc'ing the ripple-implementation list which is for technical discussions of ripplesite. You should subscribe to that list at http://sourceforge.net/mail/?group_id=120019. (There's also a ripple p2p implementation that I'm working on that will eventually merge with ripplesite's front end and replace its local payment and routing with distributed versions. I'm developing that much more actively at the moment. Let me know if you'd prefer to help with that. I'm using twisted for networking and sqlalchemy as an ORM.) The latest ripplesite codebase has been ported to Django 0.95 and is available by svn from: http://svn.ripplepay.com/ripplesite/ login as guest/guest. I'll set up commit privileges for you as necessary. I haven't packaged this code as a sourceforge release yet because it hasn't been completely tested. I see that Django has released version 0.96, which looks very compatible with 0.95 code, so we should probably be using that. I also have a trac instance that I used awhile back that I can and will revamp for ripplesite development. On 4/11/07, Kasper Souren <kas...@gm...> wrote: > > I'm one of the core developers of CouchSurfing and I would like to > help out with Ripple. I have quite some experience with Python, > but I've never used Django. Django has an excellent tutorial and documentation at: http://www.djangoproject.com/documentation/ > > But I'm running Windows with Cygwin. So I have some questions before > I try to get Apache and PostgreSQL up and running: > * Has anyone managed to run Ripple with sqlite3? How would I go ahead > to make this happen? Right now the code bypasses the django db module and uses the psycopg Postgres python DB-API module directly (a holdover from django 0.91 which didn't support transactions directly). Replacing psycopg with pysqlite in those places (payment.py and routing.py) could very well work. William Waites has made a start incorporating django transactions into the code (see the 'Ripplepay + Dialstation' thread of rippleusers for code attachments), but reports that it isn't working yet. > * Is Django able to serve pages without Apache? Yes. It has a built-in development server. You'll need to tweak it a bit to serve images and css though: http://www.djangoproject.com/documentation/static_files/ > * Are there provisions for testing stuff? Is there a test database? Will a > local installation try to send out emails to people? So far backend testing has been semiautomated using testutil.py, which allows you to populate a database from the command line, run a sequence of random payments against it, and then verify the results. I've only tested the web interface manually so far. Django 0.96 apparently has an integrated test module that may help us with more automation. A local installation will try to send emails when testing the web interface (but not when just doing backend command line testing). What I've done so far is use a gmail account: if your gmail username is 'kasper', you can send email to 'kasper+1', 'kasper+2', or 'kasper+xxxxx' and they'll all get to the same account. Ryan |
From: Ryan F. <rf...@gm...> - 2007-04-04 15:31:22
|
On 4/2/07, William Waites <ww...@gr...> wrote: > On Sun, Apr 01, 2007 at 11:55:39PM -0700, Ryan Fugger wrote: > > > > I just kept the code I had under django 0.91 because it worked. It > > would probably work fine to just replace psycopg with psycopg2...? > > But what you have looks even better. > > ... except that it doesn't work -- I finally got things to a state > where I could make offers of credit and such, and this bit of code > ends up with the 'Transaction Aborted commands ignored to end of > transaction' exception. Almost correct though... Maybe something to do with the payment.pay function being set to autocommit (done below the function, not with decorators)....? Ryan |