in reply to Piggybacking data on TCP ACK
The TCP protocol can be thought of like a state machine (as can many protocols). Data can only be sent in what is commonly refered to as the established state. The connection is only in the established state when the 3 way handshake is complete. Data is not sent in the ACK packet.
If you could provide some background as to why you want to put data in the ACK packet instead of just sending another packet we might be able to help you find an alternative. I don't see an immediate reason that one would need to put data in the ACK packet.
Wikipedia:TCP has some great entry level information into this protocol.
Update: After reading your title I infer that you may be interested in sneaking data across a network by using the 3 way handshaking. I believe that there is a better way of doing it. A packet sniffer/analyzer (like wireshark) would immediately flag the ack+data packets as not conforming to known protocols. However... you can sneak data through on the syn packets using the sequence number. By creating a raw socket you can craft your own SYN packet with a meaningful sequence number (rather than a random one). Then your own TCP engine will likely reject the SYN+ACK response (because it didn't know about your raw socket). If your TCP engine does not work that way you can always send a RST packet to terminate the process. Then you send a new SYN packet with a sequence number corresponding to the next 32 bits of your data. This will appear less suspicious (especially if you encrypt the data) because it will appear to be an old style TCP Denial of Service SYN flood attack foiled because of modern tcp engines.
Of course my inference could be completely wrong and that lengthy passage could be completely worthless to you but hopefully it helps a little.