Hi Aron, this has been considered already and the shared memory as you know it will not longer be present or needed. As for storage, it will be accessed from application in whatever manner the application sees fit. So you can use a database or a distributed hash, or memcache, whatever you see fit. All you need is a driver in the language of your choice.
On Monday 10 November 2008, Aron Rosenberg wrote: > We have been doing a lot of R+D work on making OpenSIPS work in a Load > Balancer environment and some of the issues that we are facing would be > interesting to design into the new core. > > The usage of Shared Memory to cache data in various modules makes it > difficult to scale these modules to run on several physically separate > nodes. We have contemplated using DB only mode, but the performance of > this is subpar and rapidly becomes a DB scaling issue. > > One of the items that might be interesting to think about would be a > new class of memory/object storage that I will call "Global Memory". > Global Memory could be a key/value storage system for data which > modules need to create/access/modify/update that is Dialog level rather > than transactional level. Global Memory could be backed by something > like memcached. > > Most modules that build internal caching lists from shared memory could > be converted to this new system. Usrloc, registrar, presence. > > Shared memory would then be used for single node only processing such > as transactional memory, or local copies of module data that does not > change. The load balancers that we are working with provide node level > SIP transaction persistence. > > -Aron > > Aron Rosenberg > SightSpeed Inc. > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Bogdan-Andrei > Iancu > Sent: Friday, November 07, 2008 4:32 AM > To: [EMAIL PROTECTED]; devel@lists.opensips.org > Subject: [OpenSIPS-Devel] RFC: new opensips design > > Hi all, > > As previously stated, there is a common consent that the current > design/architecture of OpenSIPS/OpenSER (inherited from SER) is no > longer able to deliver and to meet the present requirements and demands > for OpenSIPS future evolving. It is simply an inevitable dead-end that > needs to be avoided. > > Why? - I made a summary here - > http://www.opensips.org/pmwiki.php?n=Development.NewDesign#toc1 > > I guess all of you are aware of the critical problems like blocking DB > or RADIUS, blocking DNS, lack of scaling, too complicated scripting, > message changes processing , etc. > > To be able to deliver a solution that will be able to satisfy the the > growing complexity and scale of the SIP world, a new radical design is > needed. It will be process of intensive thinking and work, but the > result will be a license for the future. > > As a first step of this laborious process, collecting feedback from all > of you, about the is missing, what are your wishes, about the > known/unknown limitations, etc I just open an new web section where we > can compile all this information. > > It is not a request for solution, but a request for current problems! > We > > need to know all the problems that people facing in order to come up > with a design that will solve them all. > > Please visit: > http://www.opensips.org/pmwiki.php?n=Development.NewDesign > > and freely post there - any feedback is a valuable input and investment > in this project. > > Thanks you, > Bogdan > > > _______________________________________________ > Devel mailing list > Devel@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel > > _______________________________________________ > Devel mailing list > Devel@lists.opensips.org > http://lists.opensips.org/cgi-bin/mailman/listinfo/devel -- Dan _______________________________________________ Devel mailing list Devel@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/devel
