• (disco)

    I'll make an interesting comment someday. Someday...

  • (disco)

    Needs more context. Like why the proxy.pac was involved in the staging. I'm guessing that some system had this file deployed on it and the server with the tumbleweeds was one that should have been listed but wasn't?

  • (disco) in reply to Zemm
    Zemm:
    I'll make an interesting comment someday. Someday...

    Did you enter it in your ever-growing backlog?

  • (disco) in reply to Luhmann
    Luhmann:
    Did you enter it in your ever-growing backlog?
    Not yet, but it's on his to do list.
  • (disco)

    When the logs are empty, I always check the proxy.pac. ALWAYS! Do it too!

  • (disco)

    OOOH! I like the RFC 1918 compliant IP addresses.

  • (disco) in reply to dkf

    I'm further guessing that the original purpose of that proxy.pac was poor-man's load balancing, that the two proxy strings inside it were supposed to have the proxy servers presented in the opposite order, and that it had not been updated after the third proxy was added.

    By replacing it all with a one-liner, our hero has arranged for the first proxy listed to be hammered mercilessly and for the other two to end up with logs as mysteriously quiescent as the one that originally piqued his curiosity.

    Something like this would better fit the original intent:

    function FindProxyForURL(url, host) {
    	switch (parseInt(myIpAddress().split(".")[3]) % 3) {
    	case 2: return "PROXY 172.28.97.19:8080; PROXY 172.28.97.18:8080; PROXY 172.28.97.17:8080; DIRECT";
    	case 1: return "PROXY 172.28.97.18:8080; PROXY 172.28.97.17:8080; PROXY 172.28.97.19:8080; DIRECT";
    	default: return "PROXY 172.28.97.17:8080; PROXY 172.28.97.19:8080; PROXY 172.28.97.18:8080; DIRECT";
    	} 
    }
  • (disco) in reply to flabdablet
    flabdablet:
    Something like this would better fit the original intent:

    I'd be tempted to use a random shuffle and then generate the proxy config string from that. I'd also check after the fact whether the proxies are all getting (roughly) equally hit.

  • (disco) in reply to dkf

    Personally I like the client IP hashing approach better than the random shuffle approach, purely because it makes any given client's proxy settings completely stable; this avoids a whole bunch of potential failure modes for clients.

    I'd be very surprised to find that a random shuffle actually yields a usefully more even spread across the available proxies, too. Though you're of course completely correct to say that's something that should be measured rather than assumed.

  • (disco)

    Okay, so let's see. Heads is server 1. Tails is server 2. Hmm....on edge is server 3.

  • (disco) in reply to dkf
    dkf:
    Needs more context

    You're a funny, funny owl.

  • (disco) in reply to flabdablet

    Yeah, I was thinking that it was refactored changed to use one server, but not simplified as much as it should be.

  • (disco)

    TRWTF is anyone who uses proxy.pac to direct requests toward anything that isn't a proxy server.

  • (disco) in reply to Yamikuronue
    Yamikuronue:
    You're a funny, funny owl.

    whoooo?

  • (disco) in reply to flabdablet
    flabdablet:
    I'd be very surprised to find that a random shuffle actually yields a usefully more even spread across the available proxies, too. Though you're of course completely correct to say that's something that should be measured rather than assumed.

    It depends how many clients there are. If many of the clients come from the same organisation and are using the same external IP address, the same proxy gets hammered. Randomisation is safe, hashing isn't.

  • (disco) in reply to kupfernigk

    That would be true if the IP address were being evaluated server-side, but proxy.pac is a workstation thing; myIpAddress() returns a local workstation IP address, not the organization's possibly-shared public IP address.

  • (disco)

    What exactly does a picture of a London Underground tunnel have to do with a wonky proxy setup? The fact that there's a switch/point?

  • (disco) in reply to flabdablet
    flabdablet:
    That would be true if the IP address were being evaluated server-side, but proxy.pac is a workstation thing; myIpAddress() returns a local workstation IP address, not the organization's possibly-shared public IP address.

    Ah, but I'd do the randomization on the server that delivers the proxy.pac, so the workstations would see a trivial function returning a constant. (That might well change if they refresh it; we'd be relying on client caching, but they do that anyway.)

    Runtime code generation? Yeah, I'm happy with that.

  • (disco) in reply to dkf
    dkf:
    do the randomization on the server that delivers the proxy.pac

    That would certainly be less failure-prone than doing client-side randomization, but still looks like work for no benefit to me. I'd be interested in measurement results, of course.

  • (disco) in reply to flabdablet

    2 servers give 2 possible orders. But 3 servers should generate up to 6 strings. There is more than just rotation of the original string, it can be reversed too.

    4 servers is even more interesting: 4! strings (20)

    If the shuffle is to be local-based, just use a global counter and keep incrementing.

  • (disco) in reply to Jerome_Grimbert
    Jerome_Grimbert:
    4 servers is even more interesting: 4! strings (20)
    `<`mocking of Jerome's maths skills here`>` Also, while technically correct, you're also wrong - because you forget that first proxy on the list will be used exclusively by the client unless it's down. So your solution isn't much improvement over flabdablabadadablet's unless the proxies go down on regular basis.

    @discoursebot what do you say about inablility to escape angle brackets without monospace-ing the font?

  • (disco) in reply to Gaska

    @Gaska - Days Since Last Discourse Bug: 0

    <!-- Posted by SockBot 0.13.0 "Devious Daine" on Wed Nov 26 2014 09:46:32 GMT+0000 (UTC)-->
  • (disco) in reply to Gaska

    &lt; => <

    &gt; => >

    i see no monospacing here.

  • (disco) in reply to accalia

    That's not escaping. Besides, I like my source to be readable. ampersand-(random-letter)*-semicolon isn't readable. This is one of the things I hate most in HTML (the other being CSS).

  • (disco) in reply to Gaska

    -shrug- up to you mate.

  • (disco) in reply to Gaska
    Gaska:
    source to be readable

    Markdown - excellently readable source, WTFy interpretation!

  • (disco) in reply to aliceif
    aliceif:
    Markdown - excellently readable source, WTFy interpretation!

    IMO Markdown was best back in IRC times where it was individual people who decided what asterisks look like to them.

    Somewhat related: I also hate graphical emoticons. :& means "I don't know what to say", not throwing up FFS!

  • (disco) in reply to Gaska

    wat :arrow_right: :x: yes, :x:

  • (disco) in reply to aliceif
    aliceif:
    yes, : x:

    wat's wrong with that?

    Oh look, you can't \-escape that style of emoji in a quote. </Khaaaaaaaan>

  • (disco) in reply to Gaska
    Gaska:
    :& means "I don't know what to say"
    What about :-# and :-⁠$?

    :⁠$ and :⁠-$ in Discourse are :blush:

  • (disco) in reply to Zecc
    Zecc:
    What about :-#
    Not tangled enough to express the intent.
    Zecc:
    :-⁠$?

    :⁠$ and :⁠-$

    They don't render for me so I can't say.
  • (disco) in reply to Zecc
    Gaska:
    Zecc:
    :-⁠$?

    :⁠$ and :⁠-$

    They don't render for me so I can't say.

    Waitwaitwait. Hold the phone. HOLD FUCKING UP FOR A SECOND HERE.

    Are you saying that dollar signs ($) don't render for you?

    edit: meant to reply to @gaska, too late to fix it

  • (disco) in reply to Gaska

    If you live in a perfect world, congratulation.

    But in a real world, sticking to a rotating string for load-sharing is asking for trouble of cascading server's issue when the first one fails, all its load would go to the second... which can more easily go down on its knee... then the third get the whole traffic and the service collapse.

    So I stick with a somewhat more load-sharing solution: with 3 nominal servers, the 6 variants of proxy should be used, just to avoid cascading the problem from one server to a single next one. It's all about sharing the trouble.

  • (disco) in reply to riking
    riking:
    Are you saying that dollar signs ($) don't render for you?
    No, I'm saying the ⁠ (thing to the left of dollar sign) doesn't render for me. It's very very unusual for someone to literally write unknown character, so I buttumed you didn't mean to.
    Jerome_Grimbert:
    But in a real world, sticking to a rotating string for load-sharing is asking for trouble of cascading server's issue when the first one fails, all its load would go to the second... which can more easily go down on its knee... then the third get the whole traffic and the service collapse.
    Agreed. Except the WHOLE POINT of having backup proxy is that it WON'T go down too. Otherwise you coud just as well not give any backup at all.

    What I would do is have n-1 proxies dedicated as first-line proxies, and 1 exclusively as backup for any of them. But that requires one more server, and in the perfect world the managers live in, it's not cost effective.

  • (disco) in reply to Gaska
    Gaska:
    No, I'm saying the ⁠ (thing to the left of dollar sign) doesn't render for me. It's very very unusual for someone to literally write unknown character, so I buttumed you didn't mean to.
    I put a U+2060 character ("word joiner") in there so that :⁠$ wouldn't be rendered as :$ by Discourse (I could have written `:$` as well). Are you saying your browser renders the supposedly invisible character as a box?
  • (disco) in reply to Zecc

    Yes. Because chrome. Use a zwnj instead :‌$

  • (disco) in reply to aliceif

    ^ that. Actually, Opera. But that's still Chromium.

  • (disco)

    A lesson is learned. I'll switch to using backticks though, it's easier.

    Btw, no repro on my Chromium, under Linux.

  • (disco) in reply to Zecc

    Windows Chrome has really WTFy unicode support - as mentioned in many other threads.

Leave a comment on “An Interesting Way to Find Even”

Log In or post as a guest

Replying to comment #443505:

« Return to Article