User:Which Linden/Office Hours/2008 Oct 30

[11:02] Which Linden: the whiching hour -- I like it
[11:03] Saijanai Kuhn: one day off from Halloween though
[11:03] Which Linden: yeah
[11:04] Which Linden: I really gotta optimize these bamboo
[11:04] Which Linden: I got a macbook pro, and it should really be hitting 40 fps
[11:05] Which Linden: yet -- I only get 8 here
[11:05] Which Linden: oop -- 5 now
[11:05] Saijanai Kuhn: ha an old G5. WE're not going to mention fps
[11:05] Which Linden: o damn
[11:05] Saijanai Kuhn: looks to be about 1.0 here
[11:06] Saijanai Kuhn: slide show ;-)
[11:06] Which Linden: how do you type?
[11:06] Which Linden: kind of by faith?
[11:06] Saijanai Kuhn: with lots oof errors
[11:07] Which Linden: ha ha ha
[11:07] Saijanai Kuhn: eh not as bad as I thought 3.3 fps
[11:07] Saijanai Kuhn: almost 4
[11:07] Which Linden: yes, I look forward to the day when the viewer UI responsiveness is not tied to fps
[11:07] Saijanai Kuhn: that's just a myth though.
[11:08] Which Linden: that's interesting -- we are getting about the same fps -- implies that my giant beast of a machine isn't any faster
[11:08] Which Linden: what's a myth?
[11:08] Saijanai Kuhn: a tale told to young'ns to make them feel good
[11:08] Which Linden: oh --- the myth being that we'll ever get around to that?
[11:08] Saijanai Kuhn: I have 4.5 GB of RAM and a 6800 GT
[11:08] Which Linden: that's a decent ard
[11:09] Saijanai Kuhn: right
[11:09] Saijanai Kuhn: top of the line for that time.
[11:09] Saijanai Kuhn: not even sold anymore at the Apple store, I think
[11:09] Which Linden: yeah they only sell > 8000 these days
[11:09] Saijanai Kuhn: and intel only, I'm pretty sure
[11:10] Which Linden: def
[11:10] Which Linden: Hi latha
[11:10] Which Linden: Nice squirrel you got there
[11:10] Saijanai Kuhn: hopes for the day when the market share will be high enough for cardmakers to write drivers on their own instead of on commission
[11:10] Saijanai Kuhn: though APple might be paying them to NOT do that, come to think of it
[11:11] Which Linden: hah!
[11:11] Latha Serevi: Thanks, Which. I labeled it "chew toy" to avoid animal cruelty charges.
[11:11] Which Linden: well I think apple writes their own drivers
[11:11] Saijanai Kuhn: Jos is a control freak
[11:11] Saijanai Kuhn: nope. They pay the cardmakers to do it
[11:11] Which Linden: to be fair, their drivers are pretty stable
[11:11] Which Linden: oh....hm
[11:11] Which Linden: well, just slow then
[11:11] Saijanai Kuhn: but only for the models they carry in the store
[11:12] Which Linden: why pay for more?
[11:12] Latha Serevi: scampers off to another meeting. Apple, indeed. :-)
[11:12] Saijanai Kuhn: sure, which is why I'm hoping increased marketshare wil lead to more cards
[11:13] Saijanai Kuhn: though, knowing Jobs, he's got deals in place to prevent that
[11:13] Saijanai Kuhn: watched Jobs tear the company into little pieces 14 years ago and blame Amelio for all the bad stuff that hapened
[11:14] Saijanai Kuhn: then rode in as a White knight to save the company after Ameilo took the heat for the slash and burn
[11:14] Which Linden: I'm pretty sure no one really knows what's going on there except for the very few people at the top
[11:14] Saijanai Kuhn: brilliant guy. Smart as Woz in his own way. Hope I never meet him (Jobs)
[11:15] Saijanai Kuhn: I had enough contacts to piece together some of what happened.
[11:16] Which Linden: so, any technical topics of interest?
[11:16] Saijanai Kuhn: and you could see tha pattern: Larry Ellison woud brag about taking over Apple and Jobs would say "no way" and a few weeks later, there he'd be
[11:16] Which Linden: say what you will about Larry Ellison, dude, at least he's got an ethos
[11:16] Saijanai Kuhn: eh, trying to figure out how to frame questions intelligently. Pitched the idea of a defined outgoing pipe/cap between the client and the Agent Domain
[11:17] Which Linden: how would that differ from the event queue?
[11:17] Saijanai Kuhn: that's the question...
[11:17] Saijanai Kuhn: right now there's nothing defined for the event queue except the acki
[11:17] Which Linden: oh you mean it's unidirectional?
[11:17] Saijanai Kuhn: so, how would you send, say, gorup IM messages through the AD
[11:18] Saijanai Kuhn: right
[11:18] Which Linden: I thought that the client sents its messages to the server in the POST body
[11:18] Saijanai Kuhn: there's nothing defined for the EventQueue except the ack
[11:18] Saijanai Kuhn: and, there's no way to establish a new connection
[11:19] Which Linden: are you sure about that? does this mean the AD event queu is different than the current viewer event queue?
[11:19] Saijanai Kuhn: well, you can get the defined connections but not a new UDP replacement
[11:19] Saijanai Kuhn: the viewer event queue is to the sim
[11:19] Saijanai Kuhn: and its one-way
[11:20] Saijanai Kuhn: and you can get info on new caps from the seed cap, but you can't send messages out
[11:20] Which Linden: hm you're right that the documentation strongly implies that the request only contains an ack
[11:20] Saijanai Kuhn: hang on cat fight
[11:21] Which Linden: assumes he means literal cat fight
[11:21] Which Linden: I wonder if that's just an oversight
[11:21] Saijanai Kuhn: sigh our female 1/4 wildcat thinks she's full and tries to take on males twice her size
[11:22] Saijanai Kuhn: gets messy
[11:22] Saijanai Kuhn: at least, the markings look wildcatish and she bites the hell out of my shoulder when playing
[11:22] Which Linden: I've seen the "david gets really firece and therefore goliath is cowed" strategy work befor
[11:22] Saijanai Kuhn: none of this fingers stuff. she jumps up for the jugglar
[11:23] Saijanai Kuhn: yeah, well the male is hungry so its not fun to listen to
[11:23] Which Linden: you should maybe put a belnder on your shoulder, deter that behavior : [1]
[11:24] Saijanai Kuhn: so anyway, was hoping to fake an IIM server that could funnel at least standard group IM to the viewer, but there's no defined way to talk to the AD with large amounts of data
[11:25] Which Linden: I guess you sould send all incoming messages via a cap dedicated to that purpose
[11:25] Which Linden: "incoming" = viewer->server
[11:25] Saijanai Kuhn: right
[11:26] Saijanai Kuhn: BUT, outgoing UDP packets aren't defined for the cap--I assume they'd be XML-LLSD
[11:26] Saijanai Kuhn: and there's no format to put them in to send them out anyway
[11:26] Saijanai Kuhn: AND no cap to send them through
[11:26] Which Linden: well le'ts not confuse UDP with the event queu
[11:27] Which Linden: the UDP/TCP duality is only for transitional stuff
[11:27] Saijanai Kuhn: Tao's python AD could be modded to handle it in a jiffy, and if we have a pattern to use, we could start playing with all sorts of AD to AD and AD <=> pipes without having to wait for the Hive Mind to get around to it
[11:27] Which Linden: eventually everything will be hardcoded as tcp or as udp
[11:28] Saijanai Kuhn: sure, but the viewer is coded to handle XML-LLSD for all the UDP packets, and libsl and even pyogp can handle it that way for incoming stuff
[11:28] Saijanai Kuhn: just no output defined
[11:28] Thoys Pan: hello friends
[11:28] Which Linden: hi Thoys
[11:28] Saijanai Kuhn: Hey Thoys
[11:30] Saijanai Kuhn: so I've been nudging folks to at least *define* how it would work. We can play with it in a APython AD well before LL can get it implemented and with the right definition, we can play with experimental stuff that LL hasn't even considered, like P2P between viewers and so on
[11:30] Which Linden: anyway, I think UDP is beside the point -- I agree that the event queue should be bidirectional, and if there's a good reason for it to not be, that reason should at least be documented
[11:30] Saijanai Kuhn: right. The only thing where UDP comes in is the CAP uses XML-LLSD versions of the UDP binary packets
[11:31] Saijanai Kuhn: so the viewer can leverage the existing code
[11:31] Saijanai Kuhn: but its incoming only
[11:32] Which Linden: yeah
[11:32] Saijanai Kuhn: so I could easily (I think) work up a translation from Locklainn's packet dictionary to XML-LLSD but there's no pipe to send it over
[11:33] Saijanai Kuhn: working on an input form for UDP packets based on the dictoinary. Should be able to squirt out a form that's just a bunch of input text boxes inline based on what I have
[11:34] Which Linden: well, I'd support such a thing, though I think that the attitude is, maybe most of that stuff needs redesigning, because most of the UDP packets going out from the viewer would be much better modeled as caps
[11:34] Which Linden: yay chat lag
[11:34] Which Linden: that would be cool
[11:35] Saijanai Kuhn: right, but for now, we have no gorup IM defined, and nothing defined for establishing new (custom) types of data
[11:35] Saijanai Kuhn: and it should be easy enough to get the existing chat servr to treat the Agent Domain as a sim that forwards group IM to the viewer code
[11:36] Saijanai Kuhn: just over a CAP instead of UDP
[11:36] Which Linden: I'm a big fan of doing new stuff just for messing around, there's definitely the risk, though, that you become locked in to one of your less well-loved experiments
[11:36] Saijanai Kuhn: right
[11:36] Which Linden: S o-- why not just mess around with this in your own sandbox and report back on what you've learned?
[11:36] Saijanai Kuhn: but, without an outgoing cap design, we can't even run the risk
[11:36] Which Linden: Sure, just make something up, and try it
[11:37] Which Linden: It won't be canonical, but you'll at least learn something
[11:37] Saijanai Kuhn: ture, but would prefer a tentative desgn as a starting point, and would get more people onboard if the LIndens had "blessed" it even s an experimental design
[11:37] Rian Hirvi: Hello
[11:37] Tomm Olifone: Hi Rian
[11:38] Which Linden: I understand the reluctance of the OGP group to have tentative designs -- because no matter how much it's labeled "tentative" it becomes an effort to change it later
[11:38] Saijanai Kuhn: good point. But, if this is just billed as a test of how things might work, with no packets defined, then its just a "sandbox" pipe itself
[11:39] Tomm Olifone: I realise i've joined this discussion late, but would you fill me in on the term "CAP"?
[11:39] Saijanai Kuhn: right now there's hours of debate on how to switch to some new gorup IM standard, and no work done
[11:39] Saijanai Kuhn: a secure connection point between client and server. LL uses the format: [2]
[11:40] Tomm Olifone: Ah gotchya
[11:40] Saijanai Kuhn: and UUID actually defines what the connection does
[11:40] Thoys Pan: no https?
[11:40] Saijanai Kuhn: https that is
[11:40] Thoys Pan: =p
[11:40] Which Linden: [3]
[11:40] Saijanai Kuhn: so with https and a random UUID there's no practical way of itnercepting the data and getting anything useful out of it
[11:40] Which Linden: I guess the http-in project allows you to create http caps if you want
[11:41] Saijanai Kuhn: unless youre the proper folk
[11:42] Saijanai Kuhn: so anyway, I made my spiel to Whump yeterday and Infinity found it interesting, so maybe at Enus' office horus tomorrow we can flesh out a plan
[11:42] Tomm Olifone: Regarding group IM's... personally I would like to see an IRC implementation. No need to re-invent the wheel, right?
[11:42] Thoys Pan: what if someone loops through all ID's possible?
[11:42] Tomm Olifone: SSL can be used, too
[11:42] Thoys Pan: its alot
[11:43] Rian Hirvi: omg yeah an irc implent would be cool
[11:43] Saijanai Kuhn: right. Problem is 1) IRC doesn't quite work like LL group IM and 2) the SL viweer has this hardcoded interface that understands the current setup
[11:43] Which Linden: I'd like to take this moment to suggest that, when writing code to the LSL HTTP Server, use llRequestSecureURL() unless impossible
[11:43] Saijanai Kuhn: Thoys all UUIDs?
[11:43] Saijanai Kuhn: that's a looong loop
[11:43] Thoys Pan: yup
[11:43] Thoys Pan: very time taking
[11:44] Which Linden: like, age-of-the-universe long
[11:44] Thoys Pan: really that long?
[11:44] Which Linden: really
[11:45] Thoys Pan: howmany different combinations could there be made?
[11:45] Which Linden: "1 trillion UUIDs would have to be created every nanosecond for 10 billion years to exhaust the number of UUIDs."
[11:45] Thoys Pan: lol
[11:45] Tomm Olifone: easy peasy
[11:45] Tomm Olifone: i'll start now
[11:45] Thoys Pan: yup
[11:45] Saijanai Kuhn: efcf670c-2d18-8128-973a-034ebc806b67
[11:45] Thoys Pan: what if someone makes a lucky shot
[11:45] Thoys Pan: and guesses a important one
[11:46] Thoys Pan: =d
[11:46] Saijanai Kuhn: well, I play the lottery whenver the pot goes above $100 million...
[11:46] Which Linden: it's unlikely enough that they're much better off doing more reliable things like social engineering
[11:46] Tomm Olifone: if someone makes a very very lucky shot then I guess they have the chance of decoding a message which may well be "My bum itches" or something equally as important
[11:46] Which Linden: or hoping that our servers go tits-up and auto-pwn or something
[11:47] Thoys Pan: lol tom
[11:47] Which Linden: I guess the idea is basically that pretty much every other thing is more likely than guessing a UUID
[11:47] Rian Hirvi: you dont have to guess
[11:47] Rian Hirvi: like i had an uuid of a texture that i dont own+ script= texture on object
[11:48] Tomm Olifone: Which, do UUID's follow a certain structure which would reduce the number of permutations needed?
[11:48] Rian Hirvi: i can assume it would be usuable for objects to
[11:48] Saijanai Kuhn: yeah, but a CAP isn't just a UUID
[11:48] Rian Hirvi: to copy without permissin
[11:48] Rian Hirvi: no?
[11:48] Saijanai Kuhn: its the URL with which it is useful
[11:48] Saijanai Kuhn: if you don't know both parts at the same time...
[11:48] Rian Hirvi: ok tell me to shut up if i talk crap lolz
[11:48] Saijanai Kuhn: and most caps have a limited livfespan
[11:49] Saijanai Kuhn: lifespan*
[11:49] Thoys Pan: mosts caps have that will leave the craps open =d
[11:49] Which Linden: Tomm technically they do have a structure that consumes a few bits, but that's already accounted for in the 10 billion years
[11:49] Tomm Olifone: gotchya
[11:49] Which Linden: Also, we don't do that structure so we have those bits for randomness
[11:50] Thoys Pan: so what to do after a 10 billion years of SL™
[11:50] Which Linden: That's true, Sai, the rest of the url also needs to be guessed
[11:50] Thoys Pan: extend UUIDS to Double_uUIDS
[11:50] Which Linden: I only listen to double music!
[11:51] Saijanai Kuhn: one talk is about UUID@AgentDOmainName.com to avoid possible collisions in two asset servers
[11:51] Rian Hirvi: you expect sl to survive 10 bilion years?
[11:51] Tomm Olifone: I'm probably missing the point here, but are we essentially talking about group IM over HTTPS? and isn't that highly innefficient? :)
[11:51] Tomm Olifone: or was that a seperate topic
[11:52] Which Linden: Sai: I'm kind of against any scheme that uses naked uuids -- they should always be part of a url or uri IMO
[11:52] Saijanai Kuhn: well, anything that goes over a CAP would probably be over https in SL
[11:53] Which Linden: HTTPS isn't that inefficient, espeically if utilized in combination with other things
[11:53] Saijanai Kuhn: yeah, I understand. the issue is about the way to get at the item on the server side, I think. Which asset server has which bit
[11:53] Which Linden: i.e. keep-alives so the connection isn't reopened a lot
[11:53] Tomm Olifone: Well... you say it's not innefficient, but do you have a grasp on just how many messages are passed in groups per second?
[11:53] Which Linden: on a per-user basis it's presumably not that many
[11:54] Which Linden: we're not talking about the internal communication betwen the servers, we're just talking about the connection from the viewer to the server
[11:54] Saijanai Kuhn: I think he's worried about encryption overhead on the serverside
[11:55] Which Linden: Thats
[11:55] Which Linden: That's mostly an efficiency concern for us
[11:55] Tomm Olifone: That saijanai, but also the overhead of the negotiation etc.. i'm assuming the connections would be persistant of course, but when you begin to scale at that level the actual cpu time needed to negotiate the secure connection may become a factor
[11:55] Saijanai Kuhn: and that COULD be an issue if you had thousands of avatars in an agent domain and the AD was forwarding the messages to each avatar
[11:55] Which Linden: If there's a lot of encryption overhead, then we could get around that by adding dedicated hardware, for example
[11:56] Which Linden: The important thing to remember, is that it's a fixed amount of overhead per connection, so it grows linaearly with the number of users/communications
[11:57] Tomm Olifone: It's fixed per mesage, but there is an arbitrary number of messages per connection, right?
[11:57] Which Linden: That's much more palatable than geometric grrowth that all chat systems seem to be subjected to
[11:57] Which Linden: Right, it's fixed per some combination of message and user (there's some efficiencies if a user receives many messages)
[11:58] Saijanai Kuhn: which is why I'd like to see the original system implemented in teh AD to get things workign fast, AND to test how the system scales in the AD environment
[11:59] Saijanai Kuhn: we have known issues with scaling to 65+K users with the current system. WOuld the issues be the same using an Agent Domain? How might they be different. COuld give a lot of data for the design of something better
[11:59] Tomm Olifone: I guess the question that comes to mind, is, what is causing the current group IM system to be so massively overloaded?
[12:00] Which Linden: The AD does a good job of masking details from the client -- so it seesm to me that the underlying server implementation is much more important than the AD-> viewer interface for scalability
[12:00] Saijanai Kuhn: and with a few dozen Python Agent Domains and a few hundred comps, we could fake a system with 65K avatars pretty easy for group IM purposes
[12:00] Which Linden: Tomm: it's just got architectural problems, and no one has time to fix them
[12:01] Which Linden: If we replicated those architectural decisions to the AD, it would have the same issues
[12:01] Tomm Olifone: Right.
[12:01] Which Linden: Anyhow, I have a lunch appointment, so I should JTFO
[12:01] Tomm Olifone: now is not the time to jerk off
[12:01] Tomm Olifone: :P
[12:02] Which Linden: Heh I was thinking "Jet" but good one
[12:02] Tomm Olifone: ;)
[12:02] Saijanai Kuhn: well, the quick and dirty thing is to have the AD send teh existing packet format to the viewer to leverage how the viewer displays/handles gorup IM.
[12:02] Saijanai Kuhn: But how the AD gets the data that it conversts to the IIM format is left as an exercise for the reader
[12:02] Which Linden: Ah but there's more to it than that
[12:03] Which Linden: The viewer and server both maintain state, and the synchronization of that state constitutes some of the architectural problems
[12:03] Saijanai Kuhn: ah
[12:03] Which Linden: You need to chanage the way the viewer thinks about chat to fix some of the problems
[12:03] Which Linden: Anyhow, good discussion, sorry I can't hang around more
[12:03] Tomm Olifone: take care Which
[12:03] Saijanai Kuhn: though, handling that statein SOME way is going to be needed unless you forget about the AD entirely and just have generic IM plgins to any service
[12:04] Which Linden: Thanks for stopping by all

User:Which Linden/Office Hours/2008 Oct 30

Navigation menu

Search