5 ms·

Actually, I am not sure why you would implement TCP inside TCP. You could have just tunneled the IP packets (raw sockets, or NF_QUEUE or some equivalent) and T

by xtacy 15y ago

Actually, I am not sure why you would implement TCP inside TCP. You could have just tunneled the IP packets (raw sockets, or NF_QUEUE or some equivalent) and TCP would have taken care of everything like ACKs and packet retransmissions. There are various interesting ways to tunnel TCP inside many other protocols like ICMP, DNS, etc. The underlying principle is that since many protocols run over IP, as long as you're able to route IP, you're pretty much done. EDIT: I didn't mean to sound pessimistic. :)

xxbondsxx 15y ago
What you said is completely true, but we were going for 1984-esque post apocalyptic scenarios. Imagine every ISP shuts down traffic to all domains / addresses except a small whitelist of mega corporations (fox.net, facebook, msn, etc). Great Firewall of China status, but far far worse. You literally have no way to transmit data over the internet except through "using" a website on a browser. Obviously not a scenario that we will see any time soon (hopefully), but it was certainly a fun challenge to work on. It was also extremely hilarious to see two computers, side-by-side, chat each other actual network packets inside a browser.
- xtacy 15y ago
  Interesting worst case scenario. (Random thought) Encoding data inside video streams might give more bandwidth, as chat msgs seem to be heavily throttled.
  - xxbondsxx 15y ago
    Good idea! That would definitely require ripping open the plugin or compiling your own (and swapping it out when the page is loaded), but it would certainly enable a ton more bandwidth. I was really impressed when I first saw this image stenography on the Wikipedia article: http://en.wikipedia.org/wiki/Steganography#Digital_steganography http://en.wikipedia.org/wiki/Steganography#Digital_steganogr... If you couldn't inject your own code into the chat plugin (or had trouble faking the packets from your own), you could do the extremely low-tech solution of videochatting a screen of a slowly-changing QR code. It would make encoding super simple and still allow for a decent amount of bandwidth transmission :D Damnit! That's a good idea. 3k bytes per QR code, a conservative estimate of 15 fps, and you are at decent 45k a second with no code injection!
    - gresrun 15y ago
      You could fit many QR codes on screen at a time. Or, better yet, you could just send raw pixels as bits, white = 0, black = 1. With 1024x768 HD video, that's a possible 768K/Frame => 22.5M/s @ 30 FPS!
      - X4 15y ago
        Fun I had a similar idea on April this year, I thought about using streaming png's (nodejs) as information source, first I was thinking about using some qr-code technique to make transmissions secure. Then I thought, I could use something better like qr-code multiplication inside of a png stream that looks like a video with some qr-codes that flash from time to time. A smart-phone application would make the data readable again (decryption). You would need to whisper a secret key personally into your friends ear, so he can enter the sequence into his smartphone app. All-in-all it was a concept to use png's like videos with "cut-scenes" a-like qr-code's that get multiplied and cross-checksummed afterwards. Might sound stupid, but think about it. I wasn't approaching to solve your post-apocalyptic scenario, but to make something speedier+secure than wifi/bluetooth/infrared. What do you think? A friend who's exceptional at maths (I'm not) told me it's not possible, however I don't like when naysayers come and tell it's impossible. Still it demotivated me. Do you think it's possible? Explained in two words: "Optical Transmission"
        X4 15y ago
        I saw a friend doing a transaction, that inspired me. Here's a video to it: http://www.youtube.com/watch?v=GOQeZGe83YM http://www.youtube.com/watch?v=GOQeZGe83YM
      - philh 15y ago
        Are there any lossless video formats in common use? One is unlikely to be introduced if not, so you might need a lot more than one pixel/bit. But at the same time, you don't need to limit to black-and-white. Even just black/white/red/green/blue/purple/yellow/turquoise would be four times as much bandwidth, and I would be very surprised if even lossy video couldn't reliably distingish up to 64 colours. I don't think many people currently have 22.5M/s download speeds anyway, so it's probably not a big deal.

by xtacy 15y ago

xxbondsxx 15y ago

What you said is completely true, but we were going for 1984-esque post apocalyptic scenarios. Imagine every ISP shuts down traffic to all domains / addresses except a small whitelist of mega corporations (fox.net, facebook, msn, etc). Great Firewall of China status, but far far worse. You literally have no way to transmit data over the internet except through "using" a website on a browser. Obviously not a scenario that we will see any time soon (hopefully), but it was certainly a fun challenge to work on. It was also extremely hilarious to see two computers, side-by-side, chat each other actual network packets inside a browser.

xtacy 15y ago
Interesting worst case scenario. (Random thought) Encoding data inside video streams might give more bandwidth, as chat msgs seem to be heavily throttled.
- xxbondsxx 15y ago
  Good idea! That would definitely require ripping open the plugin or compiling your own (and swapping it out when the page is loaded), but it would certainly enable a ton more bandwidth. I was really impressed when I first saw this image stenography on the Wikipedia article: http://en.wikipedia.org/wiki/Steganography#Digital_steganography http://en.wikipedia.org/wiki/Steganography#Digital_steganogr... If you couldn't inject your own code into the chat plugin (or had trouble faking the packets from your own), you could do the extremely low-tech solution of videochatting a screen of a slowly-changing QR code. It would make encoding super simple and still allow for a decent amount of bandwidth transmission :D Damnit! That's a good idea. 3k bytes per QR code, a conservative estimate of 15 fps, and you are at decent 45k a second with no code injection!
  - gresrun 15y ago
    You could fit many QR codes on screen at a time. Or, better yet, you could just send raw pixels as bits, white = 0, black = 1. With 1024x768 HD video, that's a possible 768K/Frame => 22.5M/s @ 30 FPS!
    - X4 15y ago
      Fun I had a similar idea on April this year, I thought about using streaming png's (nodejs) as information source, first I was thinking about using some qr-code technique to make transmissions secure. Then I thought, I could use something better like qr-code multiplication inside of a png stream that looks like a video with some qr-codes that flash from time to time. A smart-phone application would make the data readable again (decryption). You would need to whisper a secret key personally into your friends ear, so he can enter the sequence into his smartphone app. All-in-all it was a concept to use png's like videos with "cut-scenes" a-like qr-code's that get multiplied and cross-checksummed afterwards. Might sound stupid, but think about it. I wasn't approaching to solve your post-apocalyptic scenario, but to make something speedier+secure than wifi/bluetooth/infrared. What do you think? A friend who's exceptional at maths (I'm not) told me it's not possible, however I don't like when naysayers come and tell it's impossible. Still it demotivated me. Do you think it's possible? Explained in two words: "Optical Transmission"
      - X4 15y ago
        I saw a friend doing a transaction, that inspired me. Here's a video to it: http://www.youtube.com/watch?v=GOQeZGe83YM http://www.youtube.com/watch?v=GOQeZGe83YM
    - philh 15y ago
      Are there any lossless video formats in common use? One is unlikely to be introduced if not, so you might need a lot more than one pixel/bit. But at the same time, you don't need to limit to black-and-white. Even just black/white/red/green/blue/purple/yellow/turquoise would be four times as much bandwidth, and I would be very surprised if even lossy video couldn't reliably distingish up to 64 colours. I don't think many people currently have 22.5M/s download speeds anyway, so it's probably not a big deal.