TCP works only with IP right?

Why would I post without being 100% correct:

Just trying to point out at a high level that if you use something else to move the TCP then you'll eventually have to implement the functionality that IP gives you.

To those that insist that you HAVE to use IP to move TCP, the answer to that is NO! That's like saying that IP has to use Ethernet. You don't. All IP provides is addressing and routing.

An example of an IP alternative is TULIP: http://www.techiwarehouse.com/cms/engine.php?page_id=2b7e10ac

A network diagram that uses TCP and NO IP:

http://citeseer.ist.psu.edu/cache/papers/cs/4058/ftp:zSzzSzpaul.rutgers.eduzSzpubzSzbadrizSzitcp-tr314.pdf/bakre95itcp.pdf#page=5

(ejb, please refer to your own post about misinformation.)

The port is in the TCP layer. Sorry, wasn't thinking there. Actually what I was thinking about is how more expensive NICs can decide if it should look past the IP header of a packet. By being able to ignore IP addresses it is not assigned it can save CPU time.Checking to see if it should listen to a port would be cool too, but that would take too much. A machine will only have a few IP addresses (at least one in the class A,B,C range, maybe a multicast address, at least one broadcast address) which wouldn't take much to store in the NIC. Listening to 1000s of ports is not unheard of.

For the author:

I'd design your chat program with two basic interfaces in mind. There will be guaranteed delivery and best effort. TCP gives you a grantee that either the packet gets to the receiving station or the sender gets an error. That's great until you want to talk Bluetooth.

Bluetooth, IR, and Serial comms are all basically the same in the WinTel world. You talk to them over a COMM port. Here you have no guarantee of delivery. Thus in the old days of downloading you had to use a protocol like ZModem to transmit files and make sure you got them all.

You'll need to implement you own guarantee of delivery for these. Basically look into what TCP provides and implement something similar with Java. Checksum, sequence number, and acks.

When you implement your chat, part of your own "network stack" would decide if it needed to transmit service guarantee information with the data at the application level or not. There is no point in incurring the overhead if TCP is being used.

UDP may work, but I don't trust it past a LAN. Some UDP packets will always be dropped by a router. One example is broadcast packets. I doubt any admins will let a broadcast come into their router. Also, because viruses propagate by broadcasting, a lot of admins may limit them to the subnet of the host. UPD is real good for streaming audio. Something when if you lose a packet you don抰 want to recover it. If you抮e listening to a game on the radio and there is a lightning strike. Would you rather hear the pop and still be in sync with the broadcast or do you want to fall a second or two behind 搇ive?coverage?I think that UPD packets are more readily dropped by a congested router. That's working on the theory that "If the application doesn't care about the packet really getting there (it would have used TCP) then why should I when I'm too busy."

awyorka at 2007-7-12 18:54:59 >

You wrote:

> See what I mean, I probably don't have it all correct either

> Why would I post without being 100% correct:

I was reacting to the first of these (mutually inconsistent) statements. It's a legitimate activity. We all make mistakes when posting: the important thing is that what's finally left in the thread is correct.

> To those that insist that you HAVE to use IP to move

> TCP, the answer to that is NO! That's like saying

> that IP has to use Ethernet.

No it isn't like saying that at all (not that anybody said it). There is no definition of TCP or IP that says it has to be over Ethernet, and there is no definition of TCP that doesn't say it operates over IP. You can implement something that looks a bit like TCP and you can call it TCP if you like but that doesn't make it TCP. It's not a question of 'those who insist that you HAVE to use IP', it's simply that there is no other meaning of TCP.

> You don't. All IP provides is addressing and routing.

TCP also relies on the packet reassembly present in the IP layer. It also relies on ICMP error conditions.

Your citations are not germane. The 'network diagram that uses TCP and NO IP' that you cited is clearly labelled 'I-TCP' which is clearly something similar to but also distinct from TCP, as the text on the same page makes quite clear. TULIP is described on the other page you cited as a link layer protocol, where (in these defunct OSI terms) IP is a network layer protocol. It also says on that page that 'TULIP lies between the MAC layer and theTCP/IP layer.' Not 'an example of an IP alternative' at all. No doubt there really are 'IP alternatives', and implementations of TCP that don't rely on IP but without IP it can't possibly be TCP as defined in the RFCs; it must be something similar-but-different. Just as I-TCP is.

ejpa at 2007-7-12 18:54:59 >