10600+ entries in 0.072s
mp_en_viaje: only if that properly involves
a whole lotta unrolling. which, im not even callin
a bad idea
mp_en_viaje: "cogentco doesn't give me ip" "ever wondered why ?" "you mean there's
a government conspiraci ?" "no. i mean there doesn't need to be one."
a111: Logged on 2019-05-28 16:22 nocredit: another question: if i run core without using segwit features (so sticking with the 1 starting addresses) am i actually protected from an eventual attack on segwit? I know that here is not core support, but there is
a way to tell core to dump the segwit part?
mp_en_viaje: by and large,
a time penalty for being late equal to the square of the years passed seems the lowest possible bottom limit. so, if you start today and sync in less than
a century, you're getting off too easy.
a111: Logged on 2019-05-28 16:11 nocredit: first of all i'd like to ask what is
a sane time for sync from zero to 100%
a111: 2016-02-14 <copypaste> it's an IDE for
a new proprietary language. it's crud, sure, but code generation isn't bad by itself
diana_coman: it still seems over the top; it's enough if client has
a known list of preferences and asks for them in that order, after all; if it doesn't get that, it goes for next and so on
diana_coman: open-ended lists like that are always
a mess and doubly so via messages
diana_coman: iirc it was specifically not
a list of meshes but at most
a list of overall graphical profiles as it were; i.e. each thing then at any time has only one option
mp_en_viaje: if you recall the whole theory with "give alternatives for gfx", server could in principle offer
a LIST of meshes. possibly different qualities, and even same quality.
diana_coman: so it needs now to keep in addition
a timestamp on data access?
mp_en_viaje: well, if client sets
a limit, then oldest-used files get wiped.
diana_coman: client asks what is
a? server says it's (name this) (position that) (mesh theother) and so on
a111: Logged on 2019-05-28 09:13 mp_en_viaje: the elegant solution for this would be for the client to keep
a list, "items the server mentioned, we asked for but never received usable answer therefore using
a default", and either go through it whenever convenient (eg, when player goes afk) or else even expose
a button for player to do himself).
mp_en_viaje: client asks what is X, gets
a response including data it doesn't have ; asks for the data.
diana_coman: honestly, as
a player, I'll then have to hack my own client, lolz
diana_coman: it does seem
a weird problem to have in the simple sense that honestly it's just easier to do it as you say: no responsibility for traffic, just shoot whatever and as many times as higher level asks for... data, not for traffic, but whatevers.
mp_en_viaje: if there IS
a queue, you can STILL get
a new request just as the queued request is satisfied.
diana_coman: what is the gain in forcing every request ->
a message to server?
mp_en_viaje: looky : if there's no queue, you can in principle get
a new request just as the old request was satisfied.
diana_coman: it depends on what arrives and when + on the contents of the queue itself really since for instance
a huge filename will fill
a whole msg
mp_en_viaje: not anymore. anyway, looky : take the object icon.jpg. the client may ask for this item icon.jpg at time intervals Ti which, as far as we know, are random. now, if you have
a queue, of fixed duration L, you offer the guarantee that "for any Tjs that are closer than L only the first does go through". this, you say, "reduces overal requests".
mp_en_viaje: lol this shiternet... im getting like 7 lines in
a bundle.
diana_coman: or you mean
a potential "race condition" there?
diana_coman: otherwise yes, no point in having the queues in the first place really;
a duplicate request can have at most the effect of increasing counter of "requests for this here object
a" if one wants then to treat them as priorities basically aka ask first for those items that have been demanded most times
mp_en_viaje: your proposal does not resolve the t4-t5 problem. having
a pending queue does not mean that the client may not decide to ask again JUST as the "requester" took them out of the pending queue.
a111: Logged on 2019-05-28 12:07 diana_coman: my proposal was to have the Requester ask "what are
a,b,c" and move those three objects into
a "pending" queue; when another request for them arrives, that's fine; when requester wakes up, it checks and prunes any that meanwhile are there so it doesn't ask again for stuff it meanwhile got
a111: Logged on 2019-05-28 12:06 diana_coman: and now re waste traffic: at t1 there are requests for obj
a, b, c; at t2 Requester wakes up and asks the server "what are
a, b, c", drops those as "done" and goes back to sleep; at t3 there is another request for
a,b,c so Requester puts them back in its queue; at t4
a,b,c arrive; at t5 Requester wakes up and ...asks the server again "what are
a,b,c?" because well, they are there in the queue, right?
mp_en_viaje: situation 2, cache (called "requester") : client will abstain from asking for some item for
a certain time after having asked.
mp_en_viaje: but let's resolve one issue at
a time, because this is not working.
mp_en_viaje: i am not saying "there is no difference". i am saying "you are proposing to produce
a mechanism to resolve
a problem you imagine exists, such that the solution's parameters are populated by guesswork and the imagined problem is not eliminated"
a111: Logged on 2019-05-28 12:07 diana_coman: my proposal was to have the Requester ask "what are
a,b,c" and move those three objects into
a "pending" queue; when another request for them arrives, that's fine; when requester wakes up, it checks and prunes any that meanwhile are there so it doesn't ask again for stuff it meanwhile got
mp_en_viaje: (fucking obviously they got the ttl wrong, who the fuck heard of ttl as
a SERVER-side setting. how is the server to know how often my pictures of jodie foster's injured snatch need refreshing ?!)
mp_en_viaje: it's remarkable, reading through all this, how much like
a web browser this client actually is. TTL next ?
BingoBoingo: nocredit: Other than running
a Bitcoin node, what else do you spend your time on?
diana_coman: nocredit: register
a key with deedbot as otherwise there can't possibly be
a "next time/later", it's always first time...
BingoBoingo: nocredit: Maybe register
a GPG key. Otherwise hard to tell whoever returns is you
nocredit: because vultr vps has sent me
a takedown notice
BingoBoingo: The TRB 3-6 week sync (CPU and disk bound) is
a strictly linear, no exceptions to verification affair
diana_coman: nocredit: for that matter if running own trb is too big
a pain/expense, I suppose you might be better served by getting in the wot and using deedbot's wallet for that matter.
BingoBoingo: The Gavin or some other shitgnome early on tried to push
a "mandatory" segwitting, but that proposal died quickly and they all now pretend that never happened.
nocredit: correct, I appreciate TRB as it removes the bloat. But 3 weeks to sync is really
a pain
BingoBoingo: It takes time, but I can also but
a blockchain on
a drive.
nocredit: another question: if i run core without using segwit features (so sticking with the 1 starting addresses) am i actually protected from an eventual attack on segwit? I know that here is not core support, but there is
a way to tell core to dump the segwit part?
☟︎ BingoBoingo: The vacant rk can indeed be rigged with the SATA snake to add
a 1tb drive.
nocredit: my problem is that i don't have
a static ip at my premises, so at home it's
a pain with the myip parameter. I was trying with
a pico vps to bypass this by set up
a private vpn, but as now i'm stuck
nocredit: is there
a recommended vps provider to use?
nocredit: first of all i'd like to ask what is
a sane time for sync from zero to 100%
☟︎ diana_coman: you can feed it manually blocks if you have them & are in
a hurry but otherwise I don't yet fully grasp your problem as such: is it stalled or is it just that you don't expect it to take longer than 1 week or what?
nocredit: for instance, with bitcoin core in half
a day I have
a synced node
nocredit: hi, thanks for the voice. Basically trb (with aggressive patch) simply is too slow to sync, and i'm using
a VULTR vps with 6 cores and 16GB of ram. For too slow i mean that after 1 week is just at block height 300k
a111: Logged on 2019-05-28 08:49 mp_en_viaje: practically, yes it;s undesirable, but the overwhelming consideration is that this undesirableness can not be managed for the client by the server, because the server suffers from
a serious knowledge problem wrt it.
diana_coman:
http://btcbase.org/log/2019-05-28#1915708 - even on re-re-read I can't follow this: where does it seem as if I'm saying in the least that server should solve this at all for client? (no, it can't, of course); my approach is to solve this in
a single point in client aka Requester rather than have it spread throughout client at every point where some part finds out it wants some data.
☝︎ a111: Logged on 2019-05-28 09:12 mp_en_viaje:
http://btcbase.org/log/2019-05-27#1915700 << if your argument is actually "the client should asynchronously ask for all data it uses defaults for AT SOME OTHER TIME than in the middle of heavy gameplay, such that all the complex gfx of everyone's armors, mounts and flying dildoes are downloaded piecemeal and while sitting around, rather than en masse whenever teleporting to
a large market town" you have
a solid point. but it's
diana_coman: my proposal was to have the Requester ask "what are
a,b,c" and move those three objects into
a "pending" queue; when another request for them arrives, that's fine; when requester wakes up, it checks and prunes any that meanwhile are there so it doesn't ask again for stuff it meanwhile got
☟︎☟︎ diana_coman: and now re waste traffic: at t1 there are requests for obj
a, b, c; at t2 Requester wakes up and asks the server "what are
a, b, c", drops those as "done" and goes back to sleep; at t3 there is another request for
a,b,c so Requester puts them back in its queue; at t4
a,b,c arrive; at t5 Requester wakes up and ...asks the server again "what are
a,b,c?" because well, they are there in the queue, right?
☟︎ diana_coman: the idea here being that well, if the caller still wants that stuff and it's not there, they will just request it again anyway so it gets again into the queue and at some point it will make it into
a message
diana_coman: now there is the apparently disputed bit: in the simplest implementation, requester can now consider that it's job is done and therefore go to sleep until next time when it might send
a message
diana_coman: whenever it decides it CAN actually send
a message to the server to ask for something, it packs together as many of those pending requested stuff as it can in one message (protocol allows
a request for several files/obj in same message) and it sends it on its way
diana_coman: so the Requester accepts all and any requests and keeps them neatly in
a queue
diana_coman: the Requester is the one who knows where data comes from, what does one need to do to obtain it, what sort of constraints there are (e.g. don't spam server with 1001 requests per second) and even what has to be obtained in order to be able to make
a request at all (e.g.
a set of Serpent keys!)
diana_coman: anytime it wants something fresh, it will place
a request with the local Requester (hence, NOT directly with the server, for all it cares the data comes from Fuckgoats really)
diana_coman: and I say "fresh" because it's not even necessarily
a case that it doesn't have it but maybe (e.g. for position) it considers it obsolete hence deletes it and wants it new
diana_coman: cache will have some default value for anything (because defaults are by type/role so not
a problem to have them upfront) and it provides those or better, simply marking them as what they are but never saying "huh, no such thing"
diana_coman: let me expand
a bit on the concrete solution I'm talking about:
diana_coman: one thing that I see there is that you seem to consider that this "request" is ONLY for art stuff; the way I see it, it's not just for that but
a generic mechanism for any sort of thing requested, be it art or contents or position or whatever
a111: Logged on 2019-05-27 22:58 diana_coman: basically I don't actually think that "needed 100 times" SHOULD translate into "send 100 requests to the server" ; something is either needed or not; it might be more needed than something else, sure but that's
a relative (and changing) ordering of requests at most, not
a traffic-generator essentially.
mp_en_viaje: the elegant solution for this would be for the client to keep
a list, "items the server mentioned, we asked for but never received usable answer therefore using
a default", and either go through it whenever convenient (eg, when player goes afk) or else even expose
a button for player to do himself).
☟︎ mp_en_viaje:
a case for "retry X magic number of times at Y magic intervals which i the designer knew ahead of time, for everyone and for all time".
a111: Logged on 2019-05-27 22:54 diana_coman: if that armor of the stars is requested once then it's wanted *anyway* so what's the point in not tracking it where the request is assembled and instead having it tracked through repeated requests; after all this "oh, still not have it" is anyway still
a look "is it in the cache now?" just that it's pushed higher up
mp_en_viaje:
http://btcbase.org/log/2019-05-27#1915700 << if your argument is actually "the client should asynchronously ask for all data it uses defaults for AT SOME OTHER TIME than in the middle of heavy gameplay, such that all the complex gfx of everyone's armors, mounts and flying dildoes are downloaded piecemeal and while sitting around, rather than en masse whenever teleporting to
a large market town" you have
a solid point. but it's
☝︎☟︎ mp_en_viaje: 2. case careful -- request is sent (p=1), if received correctly (p=2) then all is well, else new request sent (p=2.5) and if now received correctly all is well but if not yet new request sent (p=3.5) and if not well again you're looking at... well, depends how noisy/lossy the channel is, but it seems to me the careless case saves
a good chunk of bw, roughly speaking the square of the noise rate.
a111: Logged on 2019-05-27 22:51 diana_coman: while this has the advantage of being very simple indeed, all it does in fact is that it pushes the complexity
a bit higher up at the added cost of
a lot of waste traffic
a111: Logged on 2019-05-13 17:09 asciilifeform: meanwhile , in ru heathendom , (translation mine) : 'there is
a sign that distinguishes
a troo programmer from an impostor.
a true programmer , before going to bed, will put on his nightstand two glasses. one with water -- in case in the night he becomes thirsty. and one empty -- in case not.'
mp_en_viaje: and more generally i believe
a lot of software systems would greatly improved through liberal application of just this kind of carelessness. the idiots are careless at the wrong ends -- by all means, DO
http://btcbase.org/log/2019-05-13#1912968 ; do NOT "hi this is the glass from last night, how would you rate your drinking experience please fill out this form".
☝︎ a111: Logged on 2019-05-27 22:35 diana_coman: lol, internet
a la cluj
mp_en_viaje: (the programmatic logic being that as i focus on the game again, the screen will have to be redrawn, which will suck from the cache ; obviously this may not work ~exactly~ like this for
a number of reasons -- which is why it's called an ideal. it should work like this.)
mp_en_viaje: in the vhs-unix-that-never-existed ideal in my own mind, i should be able to, upon encountering for the first time
a dude i don't like, alt-tab out of the game, edit the cached file representing this dude's armor, write "dickhead" in spray paint all over the breastplate, and without any further interaction on my part see the dickhead appropriately labeled all over the game forevermore.
a111: Logged on 2019-05-27 22:33 diana_coman: not notice it until all of
a sudden nothing fits
mp_en_viaje:
http://btcbase.org/log/2019-05-27#1915695 << what would this "nothing fits" look like ? for instance, if
a client makes himself
a modfile, to have all the characters move lasciviously and otherwise sit about nude, or if joe the manga fan makes his shield sport
a tentacle pattern, the server should periodically re-enact the one-true-look with medieval officialness ? why ?
☝︎ mp_en_viaje: practically, yes it;s undesirable, but the overwhelming consideration is that this undesirableness can not be managed for the client by the server, because the server suffers from
a serious knowledge problem wrt it.
☟︎ a111: Logged on 2019-05-27 22:32 diana_coman: you mean if it timeouts on
a request then it lets it just lets it be? it makes it even simpler from my pov, not as if it's an issue but essentially I'm not sure how do you then avoid the case where you play happily offline and ...not notice it?
diana_coman: basically I don't actually think that "needed 100 times" SHOULD translate into "send 100 requests to the server" ; something is either needed or not; it might be more needed than something else, sure but that's
a relative (and changing) ordering of requests at most, not
a traffic-generator essentially.
☟︎ diana_coman: if that armor of the stars is requested once then it's wanted *anyway* so what's the point in not tracking it where the request is assembled and instead having it tracked through repeated requests; after all this "oh, still not have it" is anyway still
a look "is it in the cache now?" just that it's pushed higher up
☟︎ diana_coman: while this has the advantage of being very simple indeed, all it does in fact is that it pushes the complexity
a bit higher up at the added cost of
a lot of waste traffic
☟︎