Re: [opensource-dev] Requesting Linden Response: Please move TPVP Topics to a different mailing list
Hey, if you're looking for a review of message queueing agents, I ran across an SL review of MQs a while back when trying to choose one for our company's back end COMET server. It had value in my research and may have for someone trying to come up with chat alternatives... http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes On Fri, Apr 16, 2010 at 9:20 AM, Dale Glass wrote: > On Thu, Apr 15, 2010 at 04:09:19PM +0200, Lance Corrimal wrote: > > - 48 hours after the server code is out in the open, the 25 groups limit > has > > been lifted, AND the whole IM/group chat subsystem has been migrated to > XMPP > > (including voice via XMPP); another day and there's the possibility to > connect > > to jabber.sl.net with any xmpp client, AND talk to friends at any jabber > > service. > Very likely, but it doesn't necessarily work for SL. > > IIRC, the main issue with the group limit and IM is scaling. There can be > 70K > people online. Suppose you bump the groups limit to 100, and those 70K > people > end up belonging to 50 groups on average. Now you've double IM load, and if > you remember the days where most group chat sessions failed, it's probably > a > quite heavy loaded system. > > Jabber would have the same issue: how to handle 70K people, many with > multiple > conversations and conferences. A small jabber server is easy, but > supporting > 70K logged in accounts is a serious undertaking. > > Of course none of this would be an issue for a third party grid with 50 > concurrent users. > > > > > - 72 hours after the server code is out in the open, SVC-472 is fixed > Region crossing is complicated in SL. OpenSim doesn't seem to do a lot > better. > > If you'd be willing to improve it there, I'm sure many people would love > it. > > > But I agree, cool things could happen as a result :-) > > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] --loginuri command line option disabled in viewer2 final?
Hello, I'm having problems specifying alternative login url with --loginuri command line option. It work up to "final" viewer2 release, through all the betas, but it seem to be not working in the final release, and in the later snowglobe builds. Latif ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] --loginuri command line option disabled in viewer2 final?
Works for me on "Second Life 2.0.0 (203055) Mar 30 2010 08:11:18 (Second Life Developer)", but with a single dash. I also remember having trouble with localhost and I had to specify 127.0.0.1 instead On Sat, Apr 17, 2010 at 2:33 AM, Latif Khalifa wrote: > Hello, > > I'm having problems specifying alternative login url with --loginuri > command line option. It work up to "final" viewer2 release, through > all the betas, but it seem to be not working in the final release, and > in the later snowglobe builds. > > Latif > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting > privileges > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Requesting Linden Response: Please move TPVP Topics to a different mailing list
Scaling of group messages is simple however. With one server per group you get a long way. Lets say, 2000 connections per server on average. Usually about 1/10th of the users is online, so you can keep adding groups to a server until the total number of group members is around 20,000. Then you add a server. The routing to the servers can be done by using the DNS system, for example .groups.secondlife.com And if you throw a good socket library against it (not one using select or poll), you can add to 20,000 users per server; that still won't be a problem CPU-wise. Unfortunately some kernel tweaking and expertise is needed in that case, but just hire some IRC admin of a large server and they can tell you how to do that. On Fri, Apr 16, 2010 at 06:20:21PM +0200, Dale Glass wrote: > IIRC, the main issue with the group limit and IM is scaling. There can be 70K > people online. Suppose you bump the groups limit to 100, and those 70K people > end up belonging to 50 groups on average. Now you've double IM load, and if > you remember the days where most group chat sessions failed, it's probably a > quite heavy loaded system. > > Jabber would have the same issue: how to handle 70K people, many with multiple > conversations and conferences. A small jabber server is easy, but supporting > 70K logged in accounts is a serious undertaking. -- Carlo Wood ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Requesting Linden Response: Please move TPVP Topics to a different mailing list
It isn't just the messages that need to scale. Messaging is probably the bottom of the list of use-cases for groups in practice. It's the bit where most of the actual *problems* show up, but it isn't actually as important a part of group scaling as the rest of the group functions. On 17/04/2010 11:27 PM, Carlo Wood wrote: > Scaling of group messages is simple however. > With one server per group you get a long way. > > Lets say, 2000 connections per server on average. > Usually about 1/10th of the users is online, so > you can keep adding groups to a server until > the total number of group members is around 20,000. > Then you add a server. > > The routing to the servers can be done by using the DNS > system, for example .groups.secondlife.com > > And if you throw a good socket library against it > (not one using select or poll), you can add to 20,000 > users per server; that still won't be a problem CPU-wise. > Unfortunately some kernel tweaking and expertise is needed > in that case, but just hire some IRC admin of a large server > and they can tell you how to do that. > > On Fri, Apr 16, 2010 at 06:20:21PM +0200, Dale Glass wrote: > >> IIRC, the main issue with the group limit and IM is scaling. There can be 70K >> people online. Suppose you bump the groups limit to 100, and those 70K people >> end up belonging to 50 groups on average. Now you've double IM load, and if >> you remember the days where most group chat sessions failed, it's probably a >> quite heavy loaded system. >> >> Jabber would have the same issue: how to handle 70K people, many with >> multiple >> conversations and conferences. A small jabber server is easy, but supporting >> 70K logged in accounts is a serious undertaking. >> > -- Tateru Nino http://dwellonit.taterunino.net/ ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Requesting Linden Response: Please move TPVP Topics to a different mailing list
On Thu, Apr 15, 2010 at 3:09 PM, Lance Corrimal wrote: > Am Mittwoch, 14. April 2010 20:49:59 schrieb Joe Linden: > >> **we've had a lot of internal debate around cost/benefit of OS **... and >> we're fully committed to redoubling our commitment to make this a >> successful program*." > > > then... how about... opensourcing the SERVER (like someone pretty high up > suggested several years ago)? > > > and there's no reason to be afraid that giving away the other half of the > software would cause you longtime harm anyways... > > ...after all, the grid is more than server & client. the grid also is all > those boxes that it is running on... no way that a competitior could pull > 1 PCs out of a hat on short notice. > > on the other hand, I would like to bet actual money on the following > predictions: > > - 48 hours after the server code is out in the open, the 25 groups limit has > been lifted, AND the whole IM/group chat subsystem has been migrated to XMPP > (including voice via XMPP); another day and there's the possibility to connect > to jabber.sl.net with any xmpp client, AND talk to friends at any jabber > service. XMPP doesn't actually scale that well, unfortunately; a lot of the really big installs actually run their own protocol internally with better scaling. > - a few weeks later, all communications between client and server, and the > various server subsystems, has been ported to tcp/ssl and is transaction safe. Unlikely. Transactions are hard. There's some low-hanging fruit with regards to LSL support though. In theory, one should be able to statically verify nearly all traditional non-Mono LSL scripts, and then optionally compile them down to native code. (The static verification would probably take a day or two to code; compilation down to native code would take longer and have more interesting tradeoffs. Direct threading might be a better approach.) ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Group IMs and scalability.
On Sat, Apr 17, 2010 at 12:02:57AM -0700, Erik Anderson wrote: > Hey, if you're looking for a review of message queueing agents, I ran across > an > SL review of MQs a while back when trying to choose one for our company's back > end COMET server. It had value in my research and may have for someone trying > to come up with chat alternatives... > > http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes Um... that page links to a page of mine and says: http://www.xs4all.nl/~carlo17/irc/run-irc.htm [Carlo Wood's notes on IRC]. Of note is the fact that IRC does not guarantee message order. I must say that I can't remember to ever have said that. In fact, IRC does garantee message order from the same source (which is all you can ask for), and obviously also between messages where one is a reaction to another. For example: Person A asks "What does LL stand for?" Person B answers "Linden Lab" Then those messages ARE garanteed to be seen in that order by everyone. The *current* group IM system being used in SL manages to reverse even how I see my own messages! I wonder how often different people see messages in a different order :/ The page also says that the largest IRC channels "top out" near 3400 members. The reason for that is that in the IRC protocol every part and join is sent to all members. I added an extention to the protocol (that can be set as channel MODE) to delay join/part messages until someone actually talks. Thus, instead of: 12:10 foo JOIN #channel 12:11 bar JOIN #channel 12:15 xyz JOIN #channel 12:17 foo PRIVMSG #channel :Hello You see: 12:17 foo JOIN #channel 12:17 foo PRIVMSG #channel :Hello I've seen channels with up to 20,000 users work fine like that (large "events"). Nevertheless, even that has a limit, of course: It remains needed to send a message that is spoken on the channel / group to every participant on the channel / group. However, an interesting fact is that groups do not have to grow indefinitely: *active* participants that read messages and write messages can, say read ten times as fast as they can type, that means that beyond 10 active participants the communication will start to slow down because the humans themselves are busy catching up. Non-active participants that haven't said anything for the longest time (you can simply order them like that) to NOT need real time information: you could just queue messages (that have a limit of say 1 per second per group, no matter how large the group is thus) for ... 10 minutes, and thus 600 messages, and then start to drop messages to those that have been silent the longest time. Thus, a new message comes in (that person is bumped to the top of the active participant list). The message is queued for output. The output thread starts sending the message to the top of the active participants list working it's way down; meaning: it puts the messages in the per-member output queues, and stops doing that if the total number of memory is exceeded (note that only one pointer per message is needed, so you can serve a LOT of users that way). If the thread is still busy while a new message comes in, it also stops and starts with the new message, provided that it sent the message at least to those that were active in the past 10 minutes (which will be at most around 10 people (and not grow indefinitely), see above), otherwise the new message is queued (for 1 microsecond) until it did that. That scales to an infinitely sized group, only limited and *automatically* limited by the human digestion speed (if too many messages occur, people will bail off and therefore automatically be skipped after 10 minutes). The only limit then remaining is the problem of having a file descriptor open per member, even those that idle: in order to know if they still idle you have to read their file descriptor... and as we all know, the kernel implementation of watching many sockets isn't optimal on every operating system. There is a limit there between 4000 and 2 open file descriptors per machine. Hence, in order to make groups really scalable, you'll have to kick idling people out. For example: Someone logs into SL, is considered active and is added to all his 500 groups (or maybe the viewer will allow people to say which groups they want to join *automatically* in the future :p. Setting a limit to the number of automatically joined groups makes sense, setting a limit to the groups you can be a member of not). If does read not react to lots of those groups, so he is being kicked out of very active groups after 10 minutes, and out of non-active groups with thousands of members that are logged in, after -say- one hour. Note that typically those latter groups are of the type "access groups", groups that are used for access to a sim, not for chatting. It makes sense to treat those completely different. In the very least I'd say you shouldn't join those automatically at login. -- Carlo Wood
[opensource-dev] message queue stability
A random thought from a non-contributor after reviewing the wiki a bit... In the wiki page the biggest issue described for RabbitMQ was the idea that it could not easily be partitioned without each node having a complete description of every queue. I'm wondering if it would be feasible to separate the concept of "exchange" and "queue" onto different machines. This would be a two-level structure, where the lower level (the users or "queues") sends messages to the upper level (the groups or "exchanges") which forward the messages back down to the lower level and then to the users. If this model can be made to make any sense at all then it would permit partitioning of both users and groups without each node having to have complete knowledge. Of course one of the other major issues I see with RabbitMQ is that it doesn't save messages to disk except for disaster recovery. I hear they're trying to create a new persister that actually is willing to have some saved messages stored on disk, but otherwise I'm not sure I like the idea of messaging servers crashing whenever people hit their message cap... On Sat, Apr 17, 2010 at 12:02 AM, Erik Anderson < eri...@odysseus.anderson.name> wrote: > Hey, if you're looking for a review of message queueing agents, I ran > across an SL review of MQs a while back when trying to choose one for our > company's back end COMET server. It had value in my research and may have > for someone trying to come up with chat alternatives... > > http://wiki.secondlife.com/wiki/Message_Queue_Evaluation_Notes > ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
[opensource-dev] Fmod 3.74?
hey does anyone know where is fmod API 3.75 i cant find from http://www.fmod.org/index.php/download now it all over version 4 when sl wiki say download fmod API 3.75 what going to do? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Fmod 3.74?
Andrew Simpson wrote: > hey does anyone know where is fmod API 3.75 i cant find from > http://www.fmod.org/index.php/download > now it all over version 4 > when sl wiki say download fmod API 3.75 what going to do? > ___ > Policies and (un)subscribe information available here: > http://wiki.secondlife.com/wiki/OpenSource-Dev > Please read the policies before posting to keep unmoderated posting privileges > > Hi Andrew! Have a look in http://www.fmod.org/files/fmod3/ The 3.xx series seems to be deprecated. ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
Re: [opensource-dev] Fmod 3.74?
http://gosoftware.org/fmod_software/ Give this URL a try From: Andrew Simpson To: opensource-dev@lists.secondlife.com Sent: Sat, April 17, 2010 5:32:50 PM Subject: [opensource-dev] Fmod 3.74? hey does anyone know where is fmod API 3.75 i cant find from http://www.fmod.org/index.php/download now it all over version 4 when sl wiki say download fmod API 3.75 what going to do? ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges ___ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the policies before posting to keep unmoderated posting privileges
