On Sunday, April 7, 2002, at 12:21 AM, Mark Talluto wrote:
> By TCP, do you mean: > > accept connections on port 80 with message "connectiong" > vs > accept datagram connections on port 80 with message "connecting" The first uses TCP. The second uses UDP. UDP would make a great chat method on a local network. It can broadcast, too. It can be done simply. I think mc UDP will have trouble with a firewall, though. You might be able to send packets from behind the firewall to outside the firewall, but will have trouble receiving them behind the firewall. TCP creates a virtual wire between a port on one computer and a port on another computer. A port is simply a 16-bit number. Bytes can be sent down the "wire" both directions. The connection is not symmetrical. The connection is initiated by one end, popularly called the client. The other end accepts the connection and is often called the server. In the sockets model of TCP, the server can have lots of "wires" connected to the same port. They are differentiated by the port and computer at the other end. Other than that, ports are not shared. One computer (client) uses "open" to initiate the connection. The other (server) uses "accept" to accept one or, perhaps, more connections. You provide the connection string with "open" and you are provided one with the message from "accept". You are most likely to succeed with the client using "open" behind the firewall and the other computer (outside the firewall) being the server using "accept". A typical low-security firewall will allow you to make a TCP connection from behind the firewall to outside the firewall, but not the other way. A typical firewall will also use NAT (network address translation). The most common NAT method (and a firewall might use several) makes all connections look--from the outside--as though they are from the firewall itself. This means that the IP address of the client as seen from the server might not be that of the actual computer making the link. Though using port 80 can solve some problems, it can also create problems. Try a high port number, first. In your initial tests, use the same computer for both ends. Depending on your situation, you might want to take the person responsible for the firewall settings to lunch and explain what you are doing. Dar Scott _______________________________________________ metacard mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/metacard
