User:Which Linden/Office Hours/2008 Jan 24

From Second Life Wiki
< User:Which Linden/Office Hours
Revision as of 17:21, 24 January 2008 by Which Linden (Talk | contribs)

(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to: navigation, search

Transcript of Which Linden's office hours:

[11:01] Which Linden: morning harleen
[11:06] Harleen Gretzky: morning Which, wow, slow morning I guess
[11:06] Which Linden: Yep.
[11:06] Which Linden: It's been taking a while ever since the holidays ended
[11:07] Which Linden: Have you been to other Lindens' office hours?
[11:08] Which Linden: I've only been to Zero's and I'm curious what the other ones are like
[11:08] Which Linden: I guess I should just go.
[11:08] Harleen Gretzky: yes, I regular go to a lot of them, like Zero's, Rob's Bridie's and Torley's
[11:09] Which Linden: Are they usually sit-and-chat or question-and-answer?
[11:09] Harleen Gretzky: Most are technical, except Torley's, his are just talk about anything type
[11:10] Catherine Pfeffer: Hello
[11:10] Stormbringer Blackflag: Hi
[11:10] Which Linden: Good morning!
[11:10] Harleen Gretzky: Howdy
[11:11] Which Linden: Catherine, that's a tiny chair, which is why the seating position is so od
[11:11] Which Linden: odd
[11:11] Which Linden: I should change the text on it
[11:11] Catherine Pfeffer: ok which ;-)
[11:13] Which Linden: So, I the topic I was planning on bringing up for discussion was a "lighter" version of chttp
[11:13] Which Linden: I.e. one that can be spoken between peers that don't trust each other.
[11:14] Harleen Gretzky: doesn't teh "c" in chttp sort imply trust, lol?
[11:14] Which Linden: Well, uh, the name is kinda meaningless honestly
[11:15] Which Linden: But yeah, I guess we could call the light version "pretty sure" http
[11:16] dibbs Dovgal: We can decide on a better name alter I am sure.
[11:16] dibbs Dovgal: later*
[11:16] Which Linden: Ha ha yeah
[11:17] Which Linden: So, I guess the biggest challenge with communicating via chttp with untrusted clients is that the server is required to store state for a really long time
[11:17] Which Linden: Making it possible for a client to dos the server.
[11:17] dibbs Dovgal: By really long do you mean "undefined"?
[11:17] Which Linden: No, I mean 30 days
[11:18] dibbs Dovgal: Is this issue a data size issue?
[11:18] Which Linden: The client is supposed to tell the server to clean that up, but obviously in a dos situation it wouldn't
[11:19] Which Linden: It's a data size issue, and also the persistence operation is non-trivial in terms of performance (though I suppose that's of lesser concern)
[11:20] dibbs Dovgal: So is 30 days an arbitrary duration?
[11:20] dibbs Dovgal: Coul tth e duration of the state be scaled depending upoin the amount of required storage?
[11:21] Which Linden: That's not a bad idea -- you could choose to just store it for 5 minutes
[11:21] Which Linden: Could a dos-er still attack you?
[11:21] dibbs Dovgal: ANother option might be to determine the max storage size, and then to dump data fifo
[11:21] Which Linden: Hmmmm.... but then you risk defeating the purpose
[11:22] dibbs Dovgal: Yes true.
[11:22] Which Linden: I.e. the client has the expectation that it can retry a particular request for a certain period of time, and there are certain guarantees associated with that
[11:23] Which Linden: We picked 30 days, incidentally, because it's about an order of magnitude larger than the longest possible time a server bug preventing transactions going through would exist.
[11:23] dibbs Dovgal: Yes I can see where that could be an issue since this needs to work asynchronously.
[11:24] Which Linden: Let's try and figure out the use cases for light chttp
[11:24] dibbs Dovgal: Is there a certain length of time that could be predicted beyond which a transaction request could be declared meaningless anyway?
[11:24] Which Linden: I guess, invoking caps from the client
[11:25] Which Linden: hmm.... the client could predict in advance
[11:25] Which Linden: presumably
[11:25] Which Linden: i.e. "i want to buy this thing, and if it doesn't go through in 30 seconds, F it"
[11:25] dibbs Dovgal: Yes that is sort of what I am thinking.
[11:26] dibbs Dovgal: use cases light chttp
[11:28] dibbs Dovgal: Obviously vending is a major concern, becasue it has important transactional considerations.
[11:28] Which Linden: Ah, just thought of another use case: transmitting data during teleport/region cross
[11:28] Which Linden: In the context of the escrow, you definitely want the distribute phase to have an essentially infinite timeout
[11:29] Harleen Gretzky: Especially if it would solve the lost message cauing you to be logged off :)
[11:29] dibbs Dovgal: But I envision that as more databases are stored off world and integrated into scripting storage, that this will become more diverse.
[11:29] Which Linden: Yes.
[11:29] Which Linden: Another use case is simply between your browser and the server.
[11:29] Which Linden: For regular web sitesw
[11:30] Which Linden: Though you have to be able to modify the headers. In this regard it is harder to use than HTTPLR
[11:31] Which Linden: So, hm, I guess the notion that has been brought up here is that maybe we can just have variable-timeout chttp requests and that's sufficient to cover the use cases
[11:32] dibbs Dovgal: As a low level definition I think it would be useful to allow that.
[11:32] dibbs Dovgal: Then that cold be used in a variety of ways.
[11:33] dibbs Dovgal: For example , one could declare a level of criticality, and that might have a set of appropriate length time outs.,
[11:33] dibbs Dovgal: For example, as you say certain types migth require unlimited time,
[11:33] dibbs Dovgal: Others may time out much more rapidly if they are not as critical.
[11:34] Which Linden: I'm not convined that having a mapping from criticality to timeout adds anything though
[11:35] dibbs Dovgal: NO I am just using that as an example : that you may not need to define explicitely a timeout duration for EVERY event, if you can make definitions for classes of events.
[11:35] dibbs Dovgal: Ot server load etc that can then access the cvariable timeout value or modify it.
[11:35] Which Linden: Well I think the server cannot modify the timeout
[11:35] Which Linden: Even under load
[11:36] Which Linden: But yeah, I get that you might not want to specify the timeout explicitly all the time
[11:37] Which Linden: But how would that be implicit? Just in the destination url?
[11:37] Which Linden: (since if the client wanted to specify it, it would simply do so)
[11:37] Which Linden: Then you'd probably want the client to have a way to inspect the remote url to see what the timeout is.
[11:38] Which Linden: Ugh, and if you have client-specified timouts, you open yourself up to DoS again
[11:38] dibbs Dovgal: Could eb within a range.
[11:38] Which Linden: Right right
[11:39] dibbs Dovgal: I envision that there would eb a set off default timeouts depending upon teh type of transaction request.,
[11:39] dibbs Dovgal: These would hold if nothing was explicitely defined.
[11:39] Which Linden: How do you define the type of the transaction request?
[11:41] dibbs Dovgal: Perhaps you do not need to.
[11:41] Second Life: Your object 'store' has been returned to your inventory lost and found folder by TROI Timtam from parcel at Linden Lab HQ 3 152.28, 127.911 due to parcel owner return.
[11:41] Second Life: Your object 'store' has been returned to your inventory lost and found folder by TROI Timtam from parcel at Linden Lab HQ 3 152.28, 131.376 due to parcel owner return.
[11:41] Second Life: Your object 'Escrow demo' has been returned to your inventory lost and found folder by TROI Timtam from parcel at Linden Lab HQ 3 153.28, 129.635 due to parcel owner return.
[11:41] Second Life: Your object 'store' has been returned to your inventory lost and found folder by TROI Timtam from parcel at Linden Lab HQ 3 155.28, 129.643 due to parcel owner return.
[11:42] Which Linden: Now I'm just confused
[11:42] Which Linden: I could see if the transaction type is implicit in the server url
[11:43] Which Linden: You could also proffer up some content to the server and it could proclaim a range for that content without taking any action, but that seems needlessly circuitous
[11:43] dibbs Dovgal: And wasteful.
[11:44] Which Linden: "How long will you guarantee idempotency for this 40-meg asset?"
[11:45] Which Linden: :-)
[11:45] Dahlia Trimble: 40 meg?
[11:45] Which Linden: Some assets can get that large
[11:47] Which Linden: Avatars don't generally clear the megabyte bar though
[11:47] Which Linden: Unless you have a shitton of attachments.
[11:47] Dahlia Trimble can't imagine what would
[11:48] Tao Takashi: now I should be really here ;_)
[11:48] Dahlia Trimble: but then Bill Gates couldn't imagine anyone needing more than 640k
[11:48] Tao Takashi: hello from the snowsprint in the austrian alps :)
[11:48] dibbs Dovgal: 4 minutes of uncompressed audio
[11:49] Which Linden: Hey Tao.
[11:50] Which Linden: So, ok, we're at: each server url has a range of timeouts that it supports.
[11:50] Which Linden: The client really needs a way to discover that. OPTIONS?
[11:50] dibbs Dovgal: Th eporblem only really manifests itself during the first timeout.
[11:51] dibbs Dovgal: Becaseu that could be attached to any response in a small amount of data.
[11:51] Which Linden: Right
[11:51] Which Linden: In a header
[11:51] dibbs Dovgal: So a client could ping and see how latent teh response is.
[11:52] dibbs Dovgal: Upon response could receive teh duration range as part of teh return.
[11:52] dibbs Dovgal: Obviously during this period we are indeterminate.
[11:52] Which Linden: Right
[11:53] Which Linden: And you have to be careful because you don't want the ping itself to bother the application level
[11:53] dibbs Dovgal: NO way around that unless we can beat Einstein.
[11:53] dibbs Dovgal: laughs
[11:54] dibbs Dovgal: I would suggest that if th einitial contact does not erespond timely the entire traansaction will be at risk anyway.
[11:54] Which Linden: Another, related question: what happens if the client requests a timeout that's outside the server's range?
[11:54] Which Linden: Should the server return with a 403?
[11:54] Which Linden: Or just silently crop?
[11:54] Which Linden: Hmm....answering my own question, 403
[11:55] dibbs Dovgal: It would be polite to provide a response.
[11:55] Connecting to in-world Voice Chat...
[11:55]  Connected
[11:56] Stormbringer Blackflag: if the client wants to ping the server, it could just send a HEAD request, no?
[11:57] Which Linden: I guess but HEAD has somewhat different semantics
[11:57] Which Linden: I.e. we're assuming that the request takes some time to compute.
[11:58] Which Linden: So if the server takes a while to compute one of the headers.... then it's basically no better than doing a GET
[11:58] dibbs Dovgal: Also we want a return with more data in it than just the HTTP Header I beleive.
[11:58] Which Linden: But the semantics of HEAD are that it's the same as GET but without the body
[11:58] Which Linden: Whoa, just saw my own chat out-of-order
[11:58] Stormbringer Blackflag: food point
[11:58] Stormbringer Blackflag: *good
[11:58] Catherine Pfeffer: ;-)
[11:59] Stormbringer Blackflag: hmm i must be hungry. :P
[11:59] Which Linden: dibbs: what other data are we expeting? I'd expect that the range would be specified in like a header.
[11:59] Which Linden: I must be in California.
[11:59] Which Linden: in a header, no "like"
[11:59] Connecting to in-world Voice Chat...
[11:59]  Connected
[12:00] Harleen Gretzky: oops, looks like Dibbs crashed
[12:00] Which Linden: Looks like a buncha folks did
[12:00] dibbs Dovgal: The range could be in the header.
[12:00] dibbs Dovgal: True, not thinking there.
[12:00] dibbs Dovgal: Sorry just multitasking with the RL .
[12:00] dibbs Dovgal: lol
[12:01] Which Linden: Ha ha, yeah.
[12:01] Stormbringer Blackflag: me too. gotta head out. thanks, which
[12:01] Which Linden: We don't really have any options about where we stick chttp data since we've pledged to not mess with the body
[12:01] Which Linden: Me too
[12:01] Which Linden: I think we really got somewhere today
[12:01] Which Linden: Let's continue this conversation next week
[12:01] dibbs Dovgal: So there is enough space there to do this at least.
[12:02] dibbs Dovgal: Thank so much!
[12:02] Catherine Pfeffer: thank you (sorry I was away ... dinner ... but i logged)
[12:02] Which Linden: Thank you! I had a great time.
[12:02] dibbs Dovgal: Me 2.