Speaking of the marvels of Internet Commerce...

I am continually amazed that banks still don't fail safe, and apparently haven't learned about SYN/ACK. I mean, I know it's a recent invention, the three-way handshake is only the single most fundamental concept that makes TCP/IP work.

One of the amazing things about the design of the payment processing system is that it's easy to get into a situation where A) you know the customer's card is good; B) you've tried to charge them; and C) something has gone wrong and you don't know whether you've taken their money or not.

This happens to us every couple of weeks:

  1. Customer places an order.
  2. Us to bank: "Can I charge $30?"
  3. Bank to us: "Yes".
  4. Us to bank: "Ok, do it."
  5. ...radio silence.

If response #3 never comes, we get to show the customer an error, and that's fine. But if that response #5 times out and doesn't come back, which happens regularly, we have no idea whether the failure was that step #4 was not received, or that step #4 was received but reply #5 was lost. Sometimes it's one, sometimes it's the other. In the former case, the customer wasn't charged, and in the latter case they were! We have to fix these by hand, and there's no easy way to automate it. It sucks.

If banks understood TCP/IP, it would go like this:

  1. Customer places an order.
  2. SYN: Can I charge $30?
  3. SYN/ACK: Yes.
  4. ACK + SYN: Do it.
  5. SYN/ACK: I am gonna do it.
  6. ACK: I see that you're gonna do it.

If that was their model, then at no point does a communication failure cause a charge to be in an ambiguous state. If I never get the message in #5, the customer is not charged. If I get the message in #5 and my response in #6 is not received, the customer is not charged.

If #6 is sent but not received, then I would think the customer was charged when they were not, but the converse can't happen. There's only one possible failure mode and not two, and that failure mode is the safer one.

This is orthogonal to the complete flying clusterfuck that is AVS, unfortunately, where they put a hold on the money before validating the billing address, and then if that didn't match, often fail to release that hold. Double-you tee fuck.


Tags: , , ,

Today in Computational Necromancy: This maniac built a 10base5 Thick Ethernet network. In this century.

I am having flashbacks to inhaling fiberglass ceiling tile dust while trying to bend these ridiculous cables. The horror, the horror.
To my surprise, the network was passing traffic within seconds of first power on. The Vampire taps had worked perfectly and my terminators appear to have done the trick nicely. Just for kicks, I installed the second Vampire Tap with the network running, streaming video on one of the PCs. Not a single interruption!

I just think it's important to note here the longstanding relevance of both vampires and terminators to the Internet.

Werewolves, however, were pretty much only found on token ring.

A common belief persists that 10BASE5 used RG-8/U cable. This, for the most part, appears to be untrue. The cable used was purpose designed for 10BASE5 and manufactured by Belden under the part number 9880 (A few other compatible cables may exist). The reason #9880 cable was specified is that several variants of RG-8 exist with varying dimensions and manufacturing standards. Given that the main form of connection of MAU's to 10BASE5 networks was by the precisely designed prongs in Vampire taps, cable dimensions and dielectric consistency had to be spot on. [..]

For someone like me who hadn't encountered it before, no amount of looking at pictures could prepare for how big this stuff is. Short of high power transmission cables, it's the largest coaxial cable I've ever seen. It is also very heavy, rigid and the bend radius is absurdly large.

Previously, previously, previously, previously.

Tags: , , , ,

Ubers aren't taxis, except when they want to be.

Now That Taxis Have A Small Advantage On Market Street, Uber Wants To Be Treated Like Them

Usually insistent upon being considered a "Transportation Network Company," which is to say a technology business and not some sort of retrograde taxi service, Uber "Technologies" has changed its tune this week at the appearance of a small advantage for taxi drivers. [...]

This August the SFMTA will restrict cars traveling between Eighth and Third streets from turning onto Market Street. All vehicles will still be able to move straight ahead and cross Market, and exceptions to the turning rule will be made for taxis, emergency vehicles, paratransit vehicles, and commercial vehicles such as delivery trucks. No exceptions will be made for Uber, Lyft, et al.

[...] the company wrote in an email to the public that grossly elides the facts of the new rules. For starters, the email is called "Allow Uber On Market St.," which, okay, literally no one is saying Uber can't operate on Market. You just can't make turns like emergency vehicles or taxis, which, quick refresher, are a thing which you guys have desperately fought to not be.

Previously, previously, previously, previously, previously, previously.

Tags: , ,

  • Previously