User:Which Linden/Office Hours/2008 Jan 24
< User:Which Linden/Office Hours
Jump to navigation
Jump to search
Revision as of 16:48, 8 February 2008 by Which Linden (talk | contribs) (Getting rid of non-chat transcript that snuck in here.)
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: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: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. |