JonWienke@aol.com writes:
A tcp header contains quite a bit of useful information.. but most of it wouldnt be easily manipulated (by me) to get a bit. [header checksum twiddling...]
This is a bad idea, because in addition to the extra processor overhead, it is an incredible waste of bandwidth. For a 512 byte packet, you are only getting .02% efficiency, because you wouldn't be able to use the actual data in the packet; otherwise someone would probably notice the increased error rate if you dink around with the checksum.
I think that the original poster meant twiddling some of the (relatively) unused fields of the header which most routers and applications do not care about, the type-of-service field or priority would good place to start. This would have no effect on the data in the packet, particularly if you fiddle at the IP level instead of TCP. While it is a low bandwidth comm channel, it has a couple of advantages which you seem to overlook: -It can be applied by two routers which are in the middle of the connection. The two endpoints of the TCP/IP connection would not even notice. For example, if I control a router "upstream" of a major connection point and the site I wish to communicate with is in a similar position then I can run the subliminal channel in a "spread spectrum" mode across many connections and the packets can get reset to their original settings by the other site. The user whose stream we fiddled with does not even know that they were used as carrier wave... -While the per-packet information rate is low, such a system has a _lot_ of packets to work with and a much larger choice of endpoints. Your hypothetical .WAV file may pack more information in, but there are a miniscule amount of such files moving on the Internet; just by transmitting such a file you could be suspect (honestly, how many soundfiles do you think you could ship around before people get suspicious...) By hiding the information in the lower layers of TCP/IP you also make it less likely to be noticed; unless someone hooks up a packet sniffer and filters at the IP level the stream will go unnoticed, while a soundfile is an application-level communication and much easier to watch. It is, in effect, hiding the channel in the low-order bits of the comm channel used to transmit your soundfile... -An application encoding method (pictures,soundfiles, etc.) also needs a "reason" for being sent. You can legitimately send packets for no reason whatsoever, at least from the users perspective (e.g. DNS lookups, ICMP messages, faked fragments, etc.) A packet system also has a constant stream of traffic to play with; you could run TCP/IP _on top of such a system_! Passing soundfiles and images back and forth would not work for interactive communication, it is UUCP at best. jim