User:Which Linden/Office Hours/2008 May 8

• [11:03] XLR8RRICK Hudson: Hello Which
• [11:03] Which Linden: Hello there
• [11:03] XLR8RRICK Hudson: I was just looking at the process of the buying of objects
• [11:04] Which Linden: In what way?
• [11:04] XLR8RRICK Hudson: the flow chart behind you
• [11:04] Which Linden: Ah yeah
• [11:05] XLR8RRICK Hudson: I had no idea it was like that
• [11:05] Which Linden: You know this is a future plan, not the way it works now, right?
• [11:05] XLR8RRICK Hudson: oh I see
• [11:05] Which Linden: If it worked that way, perhaps it would succeed more often :-)
• [11:06] XLR8RRICK Hudson: lol I take the oppertunity of failed transactions to make my customers happy
• [11:06] Which Linden: I appreciate that attitude
• [11:06] Which Linden: That is really cool.
• [11:06] XLR8RRICK Hudson: I have almost a 100 % customer retention
• [11:07] Which Linden: What is your business in?
• [11:07] XLR8RRICK Hudson: my wife creates Stained Glass and low prim furniture
• [11:07] XLR8RRICK Hudson: she is the artist
• [11:07] XLR8RRICK Hudson: I just do the Mentoring
• [11:08] Which Linden: Cool
• [11:08] XLR8RRICK Hudson: she is in heaven here SL was made for her
• [11:09] Which Linden: Ha ha
• [11:09] XLR8RRICK Hudson: yes
• [11:09] Which Linden: How long have you two been selling stained glass?
• [11:09] XLR8RRICK Hudson: about 1.5 years now
• [11:09] Morgaine Dinova: Ni Which :-)
• [11:09] Morgaine Dinova: Hi too :-)
• [11:09] XLR8RRICK Hudson: Hello Morgain
• [11:10] XLR8RRICK Hudson: e
• [11:10] Which Linden: Hey Morgaine
• [11:10] Which Linden: Hi Sai
• [11:10] Saijanai Kuhn: wow strange behavior with walkig. Like molasses
• [11:10] XLR8RRICK Hudson: hiya Saijanai
• [11:10] Morgaine Dinova: Hi XLR
• [11:10] Which Linden: The sim seems to be struggling a bit
• [11:10] XLR8RRICK Hudson: yes that happened to me too
• [11:10] Which Linden: Actually a lot, fps is 11
• [11:11] Entering god: mode, level 200
• [11:11] XLR8RRICK Hudson: 9 for me
• [11:11] Saijanai Kuhn: well I'm often at 1fps, this is relatively smooth, just slow-moving
• [11:11] XLR8RRICK Hudson: a little laggy at 123.5 ms
• [11:11] Morgaine Dinova: This is an antique nVidia 5200 PCI machine, so not surprised at 6 FPS.
• [11:12] XLR8RRICK Hudson: I have a X300 GPU not even supported anymore
• [11:12] Morgaine Dinova: But I get 60 FPS in similar surroundings on Core2 + 8600GT
• [11:12] Which Linden: My bamboo is the trouble
• [11:12] Morgaine Dinova: Lack of water?
• [11:12] Which Linden: It hurts the video card
• [11:12] Which Linden: It has multiple high-res alpha textures that are interleaved
• [11:13] Which Linden: And flexi!
• [11:13] XLR8RRICK Hudson: yes it looks like the Alpha is taking a lot of resources
• [11:13] Saijanai Kuhn: that might be. Usually I'm here a little early, so I dont' walk around while you are here
• [11:13] Which Linden: (just cleaning up the physics in this sim, gonna be distracted fo a mo)
• [11:14] XLR8RRICK Hudson: np
• [11:14] XLR8RRICK Hudson: 8600 must be nice
• [11:14] Which Linden: There we go
• [11:14] Morgaine Dinova: 8600 is very cheap, 60 quid, but nice yes.
• [11:15] Saijanai Kuhn: is stuck with whatever limited video cards Apple paid nvidia to write Mac compatible drivers for
• [11:15] XLR8RRICK Hudson: yes I would need a more powerfull power supply as well
• [11:15] Which Linden: I am very sad about the nvidia driver situation
• [11:15] XLR8RRICK Hudson: CPU: Intel Pentium 4 (Unknown model) (3000 MHz) Memory: 1023 MB OS Version: Microsoft Windows XP Service Pack 2 (Build 2600) Graphics Card Vendor: ATI Technologies Inc. Graphics Card: RADEON X300 x86/SSE2 OpenGL Version: 1.5.4901 WinXP Release
• [11:16] XLR8RRICK Hudson: yes the VBO problem
• [11:16] Which Linden: Or whatever
• [11:17] Saijanai Kuhn: I'm using a 6800GT on my PowerMac. There's a more powerfull 7800 available, but it still costs $400 :-(
• [11:17] Which Linden: I have a 6800 in my desktop at work, it's not bad actually.
• [11:17] Saijanai Kuhn: Apple likes to discourage upgrdaes.
• [11:17] Saijanai Kuhn: Macs suck for games graphics though.
• [11:17] Which Linden: Had some strange bugs that the windlight team wontfixed a few times :-)
• [11:17] Saijanai Kuhn: so the 6800 is quite slow
• [11:18] Saijanai Kuhn: fps of 6.2
• [11:19] Which Linden: So what's everyone been up to? I see that the OGP is proceeding at pace
• [11:19] Saijanai Kuhn: anyway, was describing to Morgaine my little multi-process experiment
• [11:19] Saijanai Kuhn: OGP so you heard about the name change
• [11:19] Saijanai Kuhn: already misses the SLGOGP
• [11:19] Morgaine Dinova: lol
• [11:20] Which Linden: I didn't hear about the name change, I was just abbreviating
• [11:20] Which Linden: Cause goddamn.
• [11:20] Morgaine Dinova: lol
• [11:20] XLR8RRICK Hudson: brb
• [11:20] Which Linden: The multiprocess agent domain server?
• [11:21] Saijanai Kuhn: the multi-process script thing I did to see how many python interpeters needed to bring my mac to its knees
• [11:21] Morgaine Dinova: Haha, nah, Sai's exercising script. The multi-process client of a few months ago is on hold, from my end at least.
• [11:22] Which Linden: So, wait, what does your script do?
• [11:22] Saijanai Kuhn: well, it seems to me that using tat micro-POST server allows for IPC
• [11:22] Saijanai Kuhn: gave you Sample faux-POST server script.
• [11:22] Which Linden: Right, that's a very minimal web server
• [11:23] Saijanai Kuhn: just wanted to see if I could use it for IPC for the login bots
• [11:23] Which Linden: Mmmmm... Isee
• [11:23] Saijanai Kuhn: so one size fits all for IPC on the same machine or a remote
• [11:23] Which Linden: So the login bots would contact this micro-post server for....unspecifiec IPC needs.
• [11:24] Saijanai Kuhn: actually, the login bots would have the micro-post server
• [11:24] Saijanai Kuhn: the GUI or command line script would send commands to each bot
• [11:24] Saijanai Kuhn: via POST
• [11:25] Saijanai Kuhn: and the bot would handle_POST and parse and handle the command
• [11:25] Which Linden: Ah! So it's an embedded web server for control purposes. Nice. I love that stuff.
• [11:26] Saijanai Kuhn: either you or Donovan mentioned the idea ages ago concerning the multi-process client. Send all IPC via web semantics
• [11:26] Saijanai Kuhn: that way you could have a distributed client
• [11:26] Morgaine Dinova: That doesn't help with the eventqueue though Sai, since we must operate over TCP streams started from the client end.
• [11:26] Saijanai Kuhn: In this case, I'm controling bunches of BOTs, riather than modules in a single client
• [11:26] Morgaine Dinova: Ie. a "real" webserver-type listener won't work.
• [11:26] Saijanai Kuhn: right, this is just for a GUI interface for the bot
• [11:27] Saijanai Kuhn: script with GUI sends commands via POST to each bot
• [11:27] Morgaine Dinova: Yeah, fine for local activity, since all participants would be within the same NAT, if there is one.
• [11:28] Saijanai Kuhn: well, for test harnes purposes, I don't think it matters mcuh if the bot is on the other side of the world
• [11:28] Which Linden: Yeah, I really like that paradigm. I've used it for a buncha projects.
• [11:29] Morgaine Dinova: Well, the HTTP open won't get through to the client mini-server even if it's from right next door in the same ISP.
• [11:29] Saijanai Kuhn: 100,000 bots logging in to stress test the new login server, or to stress test a new group IM protocol. All of them sending the same chat message through the IM protocol
• [11:29] Which Linden: Donovan even had it so that you could interact with a a running python process through an interpreter over AJAX
• [11:29] Saijanai Kuhn: hmmm, why not MOrgaine, or am I misunderstanding something
• [11:30] Morgaine Dinova: Sai: NAT
• [11:30] Saijanai Kuhn: ah.. hmmm
• [11:30] Morgaine Dinova: Not everyone is behind NAT of course, but it's extremely common, since broadband routers use it by default
• [11:30] Which Linden: Yeah won't work so well from home
• [11:30] Saijanai Kuhn: yeah, well darn
• [11:31] Which Linden: You could have it do comet to a "control" server that then does reverse-http to the bot....
• [11:31] Saijanai Kuhn: though... no reason why you coulnd't be using port 80 is there?
• [11:32] Morgaine Dinova: Sai: it's not the choice of port, it's that the addresses behind a NAT are private and non-routable.
• [11:32] Saijanai Kuhn: for remote bots, use ip:80. For localhost, use 127.0.0.1:xxxx
• [11:32] Saijanai Kuhn: arg. So unused to web stuff via my home comp. Forgot about that
• [11:33] Morgaine Dinova: Internet backbones don't route to private addresses, by design.
• [11:33] Saijanai Kuhn: oh well, within a LAN it would still be useable
• [11:33] Morgaine Dinova: Sure
• [11:33] Saijanai Kuhn: which solves Enus's problem if he wants to use it
• [11:34] Morgaine Dinova: We can run reverse HTTP over a TCP stream established from the client end though. Just needs some creativity. A TCP stream is a TCP stream after all ... there's nothing special about the one set up by an HTTP open.
• [11:34] Saijanai Kuhn: I guess the principle still could be used via one of the more elaborate solutions you mentioend, for a distributed client or set of bots (or both)
• [11:34] Which Linden: Also you could portforward through a nat
• [11:34] XLR8RRICK Hudson: I must fly Be Well everyone
• [11:34] Morgaine Dinova: Cya XLR
• [11:34] Which Linden: Good to see ya
• [11:35] Saijanai Kuhn: so with the keep alive thing, the socket stays handy indefinitely for 2-way communication?
• [11:35] Which Linden: It could. But honestly I kinda think reverse-http is tricky. I was only proposing it semi-seriously
• [11:35] Morgaine Dinova: Aye, but that's a separate issue. Could simply change the socket options to no timeout instead.
• [11:36] Which Linden: Mostly due to the way the http spec defines socket closing/opening semantics.
• [11:36] Which Linden: Yeah
• [11:36] Which Linden: Also there's the problem that most http libraries expect the sockets to go the other way, etc etc.
• [11:36] Saijanai Kuhn: regardless, I THINK that I could design the entire thing to work locally, and work out a more robust solution later on without rewriting anything but that one bit of server code
• [11:37] Saijanai Kuhn: handle_POST calls do_command. As long as the MoreRObustCOde calls do_command, the rest of the system need not change
• [11:38] Which Linden: Agreed that it's better to just tackle it locally
• [11:38] Which Linden: Ooooh... also don't forget about ipv6, the nat-killer
• [11:38] Which Linden: Morning Squirrel
• [11:38] Saijanai Kuhn: still working on ip4
• [11:38] Squirrel Wood: Hellu ^^
• [11:39] Squirrel Wood: Yum. IPv6...
• [11:39] Morgaine Dinova: The tidy and symmetric way of designing is with both client and server ends having their own HTTP server, and all HTTP opens going them alone. Then, you create a TCP pipe (or a bundle of them) between client and servet, from client end, and you add forwarding to those local webservers using tunneling through the TCP stream(s) based on URI.
• [11:39] Saijanai Kuhn: I've got Steven's Advanced UNIX programming and UNIX Network programming, so in theory I can learn this stuff
• [11:39] Morgaine Dinova: Hiya Squirrel
• [11:40] Saijanai Kuhn: oh, and vol one of his TCP book
• [11:40] Saijanai Kuhn: but its buried in a box in the garage
• [11:40] Which Linden: Nice
• [11:40] Which Linden: TCP is an interesting protocol
• [11:40] Which Linden: I was just reading about how its checksum is not as robust against corruption as it could be
• [11:40] Saijanai Kuhn: but all of that is secondary to getting the system to work with my simple server
• [11:41] Morgaine Dinova: Stevens is good, and Comer. But there's no replacement for playing with it all.
• [11:41] Saijanai Kuhn: There are 3 socket handler types I need to worry about for a test client: UDP (for 5 sims), TCP (for 5 sims) and teh command handler
• [11:42] Squirrel Wood: udp... that thing which is blocked by many company networks...
• [11:42] Morgaine Dinova: Which: yeah. That's why SCTP expanded the checksum.
• [11:42] Saijanai Kuhn: so for the python test scripts, I'm ignoring child sims/avatars, and just handling the main sim UDP and EventQueueGet
• [11:43] Saijanai Kuhn: I can stick both UDP and EQG handlers in a loop of some kind but not sure how to handle the blocking thing. LIkewise with the command handler.
• [11:43] Saijanai Kuhn: Morgaine says loops are considered bad here
• [11:43] Squirrel Wood: I just wish SL would make use of my 25 mbits of bandwidth :p
• [11:44] Saijanai Kuhn: what happens if you raise your network bandkwith setting in the client
• [11:44] Morgaine Dinova: Which: SCTP is looking nicer and nicer to me every time I read more about it. I'm going to try to use it for something serious to get experience.
• [11:44] Squirrel Wood: it is capped at 1500kbps
• [11:44] Squirrel Wood: and even that is throttled down
• [11:44] Which Linden: Don't forget the sim sends every packet to you so there's a cpu limit to what it can do
• [11:45] Which Linden: Yeah, to handle the blocking, it's probably easiest to use a non-blocking framework. There are a few options: pyevent, twisted, eventlet.
• [11:45] Morgaine Dinova: Which: well that itself needs changing.
• [11:45] Which Linden: Oh and stackless
• [11:45] Which Linden: Morgaine: agreed, but that's the situation on the ground, as it were
• [11:46] Saijanai Kuhn: each of those looks like it might be overkill, but not sure at this point. ALl this stuff is new to me
• [11:46] Morgaine Dinova: Which: we were actually discussing that at one of Zero's OH's. Stopping things from being downloaded when not wanted will help enormously for scalability.
• [11:46] Morgaine Dinova: Too much currently assumes "the standard client".
• [11:47] Which Linden: Where "things" == "textures/objects"?
• [11:47] Morgaine Dinova: Which: almost everything should be optional. In fact, if you don't request something via its cap, you should simply not get it, by default :-)
• [11:47] Saijanai Kuhn: you can do that now a bit. Just neglect to fully rez via AgentUpdate. A LOT of packets are left off in that case
• [11:48] Saijanai Kuhn: https://wiki.secondlife.com/wiki/Image:Second_LIfe_Login_UML2.png
• [11:48] Saijanai Kuhn: abvout 80% of them I think
• [11:48] Saijanai Kuhn: I believe (can't test yet) that IM and chat are still available, as well as inventory. NOt sure about local inventory passing
• [11:50] Saijanai Kuhn: Just comment out the AgentUpdate call before you start the UDP look in my script, and suddenly the avatar stays in-world 5x as long for a given nuber of packets
• [11:50] Which Linden: If you're put on the interest list to get object/texture updates, it's still sim-gated
• [11:50] Saijanai Kuhn: doesn't get sent though as far as I can tell
• [11:50] Saijanai Kuhn: or at least many are not
• [11:51] Saijanai Kuhn: the itnerest list is the issue with having 100s of low-impact bots on the sim. As long as they are dealt with as full-blown avies, they impact the sim a lot more than they probably need to
• [11:51] Which Linden: Yeah, but even if teh sim has a interest list, it's not like the interest list process itself has to send you the data
• [11:52] Saijanai Kuhn: Kelly LInden suggeseted that such bots should have their own type:not avie, not prim
• [11:52] Morgaine Dinova: Which: no point holding and updating things on the interest list though, if they're never sent :-)
• [11:52] Which Linden: Well, how would the sim save resources if it knows it's a bot? Use a simpler interest algorithm?
• [11:52] Which Linden: Yeah, or the bot can just say "not intrested in anything"
• [11:52] Saijanai Kuhn: Kelly seemed to think it would be easier to create a new type than to rewrite the entire interest list handling code
• [11:52] Which Linden: But, I predict that the next generation of bots *will* be interested in objects.
• [11:53] Saijanai Kuhn: well, but not for *drawing*
• [11:53] Morgaine Dinova: Sai: that's a good idea of Kelly's. The <presence> of an av-less login still needs its own object, indeed.
• [11:53] Saijanai Kuhn: NPCs might want to know the loction of objects and avies, but nothing else
• [11:54] Saijanai Kuhn: your most complicated boss mob encoutner doesn't need to know the 3D geometry details of the avies its fighting
• [11:54] Which Linden: And it certainly doesn't need to know the textures
• [11:54] Which Linden: Although, as it gets more sophisticated, it will, to see what things are transparent
• [11:54] Which Linden: It becomes an AI problem at that point though
• [11:55] Saijanai Kuhn: yeah, there's that. But then, it can be handled by a regular avie
• [11:55] Morgaine Dinova: People need to get over the concept of "bot". It's a continuum, or will be. Is a regular client whose operator has gone out for lunch a "bot". The concept makes no sense.
• [11:55] Morgaine Dinova: And even the regular client will be script-controlled in due course.
• [11:56] Saijanai Kuhn: well, a avie that needs no info except the location of things int eh sim will almost certainly not be controlled by a human.
• [11:56] Saijanai Kuhn: libsl scripted bots are already qutie common. Ask Dahlia about her avie pets
• [11:56] Which Linden: It could be a specialized viewer for the disabled.
• [11:57] Saijanai Kuhn: anyway, getting back to my test harness thing. So I should look at things like evetnlet, twisted, etc...
• [11:58] Saijanai Kuhn: Does eventlet handle UDP sockets?
• [11:58] Which Linden: Yes it does
• [11:58] Which Linden: I don't think you need anything spectial for that though
• [11:58] Which Linden: UDP is "inherently non-blocking"
• [11:59] Saijanai Kuhn: kool So I might be able to do the entiere login bot including comand line processing via eventlet
• [11:59] Which Linden: Yeah, I don't see why not
• [11:59] Which Linden: Eventlet doesn't provide command-line parsing
• [11:59] Saijanai Kuhn: just ave a trio of handlers: UDP, EQG, command,
• [11:59] Which Linden: Yeah
• [11:59] Saijanai Kuhn: the commandline was the OST micro-server
• [11:59] Saijanai Kuhn: POST
• [12:00] Morgaine Dinova: And you have a "GUI" built in anyway, since the microserver could trivially be serving a webpage.
• [12:00] Saijanai Kuhn: so if I can get it working for login it would probably work for any non-graphical aspect of the client
• [12:01] Which Linden: Yep
• [12:01] Which Linden: Hey, I gotta run today, can't dawdle.
• [12:01] Which Linden: But I will be happy to help you with eventlet, Sai.
• [12:01] Morgaine Dinova: Tut tut, 1 minute overrun already :-)
• [12:01] Saijanai Kuhn: ah, kool hadn't thought of that. So for a single test avie, it could serve its own webpage, and for mutliple avies, you can have one webpage do double duty
• [12:02] Which Linden: It's not well-documented. :-)
• [12:02] Saijanai Kuhn: thanks for your input which
• [12:02] Which Linden: Thank you.
• [12:02] Morgaine Dinova: Sai's the documentation demon, let him at the eventlet doc :-)
• [12:02] Which Linden: Yeah sorry about the time, I am at home which means I gotta skeedaddle in to the office for a meeting
• [12:02] Saijanai Kuhn: hire me first
• [12:02] Which Linden: LOL
• [12:03] Morgaine Dinova: Good point! Hire him, it's only fair :-(
• [12:03] Saijanai Kuhn: still (barely) hopeful about job
• [12:03] Saijanai Kuhn: have to finish the current login protocool and show it to Rob
• [12:03] Saijanai Kuhn: https://wiki.secondlife.com/wiki/Image:Second_LIfe_Login_UML2.png is the UML for it
• [12:03] Morgaine Dinova: I don't think LL zhr have read "Tao of Linden", or someone would have picked up Sai's case:-(
• [12:03] Morgaine Dinova: LL HR
• [12:03] Which Linden: Well, maybe
• [12:04] Which Linden: I got no say on that topic
• [12:04] Which Linden: But, laters!