3 ms·

Back in the days of modems I worked at a company that was selling video games over the internet. The owner was a former IBM middle manager that thought she knew

Back in the days of modems I worked at a company that was selling video games over the internet. The owner was a former IBM middle manager that thought she knew a lot more about technology then she actually did - not uncommon. One day she decides that she wants the game downloads to work one byte at a time so that people could be absolutely sure they received them and could not complain they had been cut off and didn’t receive the complete file (Was very common for people to download the games then dispute the transaction with the credit card company, they got to keep the game and we always lost the dispute). We tried to explain that sending the file a byte at a time, depending on the protocols involved, would turn a one megabyte file into a 93 megabyte transmission that would take more then a day to complete as each byte was transmitted and acknowledged but she could not be swayed. So instead we made the system call for each byte and thanked god for John Nagle. https://en.m.wikipedia.org/wiki/Nagle%27s_algorithm https://en.m.wikipedia.org/wiki/Nagle%27s_algorithm

CGamesPlay 7y ago
This is an interesting example of a business idea resulting in an asinine technical solution, but thinking about the actual business problem, it seems like you would want to transmit an encrypted blob to the customer, and then transmit the decryption key at the end using your "very reliable" communication method. The decryption key isn't "usable" until the entire thing is received, which means the entire game isn't usable until then either. (I don't think this actually solves the real he-said-she-said problem, but I think it would appease the PM in charge.)
- Cogito 7y ago
  There has probably been a lot of thought into problems like this, and it would be interesting to hear any real solutions used. My addition would be to pre-calculate a checksum for the encrypted blob, and only send the decryption key after receiving the checksum from the downloader. You would then have a clear audit history showing that the user had downloaded the file completely, though you still have the possibility that they would claim the encryption key wasn't sent, or similar. I also wonder what the impact of (presumably) having to encrypt the file for each downloader individually.
  - zxcvbn4038 7y ago
    The trick is that it’s not really a technical problem, the people receive the download just fine, they just don’t like the game, or get tired of it after a few minutes, or never had any intention of paying in the first place - so they do a charge back via their credit card issuer. That is successful just about all the time unless the cardholder and merchant have the same bank, or it is an oil/gas transaction (petroleum companies have some special arrangement where the card has to be reported stolen in order for a chargeback to be successful). I always thought that giving away a couple level demo of the game was the best way to weed out the first two categories of people. I don’t think there is much you can really do about the third. As much as it gets abused I’m glad the chargeback system exists, I’ve needed it a few times.
emmelaich 7y ago
All praise @animats

CGamesPlay 7y ago

This is an interesting example of a business idea resulting in an asinine technical solution, but thinking about the actual business problem, it seems like you would want to transmit an encrypted blob to the customer, and then transmit the decryption key at the end using your "very reliable" communication method. The decryption key isn't "usable" until the entire thing is received, which means the entire game isn't usable until then either. (I don't think this actually solves the real he-said-she-said problem, but I think it would appease the PM in charge.)

Cogito 7y ago
There has probably been a lot of thought into problems like this, and it would be interesting to hear any real solutions used. My addition would be to pre-calculate a checksum for the encrypted blob, and only send the decryption key after receiving the checksum from the downloader. You would then have a clear audit history showing that the user had downloaded the file completely, though you still have the possibility that they would claim the encryption key wasn't sent, or similar. I also wonder what the impact of (presumably) having to encrypt the file for each downloader individually.
- zxcvbn4038 7y ago
  The trick is that it’s not really a technical problem, the people receive the download just fine, they just don’t like the game, or get tired of it after a few minutes, or never had any intention of paying in the first place - so they do a charge back via their credit card issuer. That is successful just about all the time unless the cardholder and merchant have the same bank, or it is an oil/gas transaction (petroleum companies have some special arrangement where the card has to be reported stolen in order for a chargeback to be successful). I always thought that giving away a couple level demo of the game was the best way to weed out the first two categories of people. I don’t think there is much you can really do about the third. As much as it gets abused I’m glad the chargeback system exists, I’ve needed it a few times.

emmelaich 7y ago

All praise @animats