User:Which Linden/Office Hours/2008 May 8

From Second Life Wiki
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.
  • [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!