Creating a TCP/IP connection on already-networked computers

[John Salerno]

Let me see if this question even makes sense...I'm reading Core Python
Programming and I jumped ahead to the more specific topics like network
programming. I plan to follow along with the example in that chapter and
create a socket connection between my desktop and laptop.

However, these two computers are already connected on my home network
(using the Windows Network Setup Wizard), so I was wondering if this
will have any effect on what I might try to do with Python. In other
words, if the program I write actually works and allows the two
computers to speak to each other, will that be a result purely of the
program, or will it have anything to do with the fact that they are
already on a home network together? (i.e. there's another variable in play?)

Thanks.

 

[John Salerno]

if the program I write actually works and allows the two
computers to speak to each other, will that be a result purely of the
program, or will it have anything to do with the fact that they are
already on a home network together?

Here are the two programs. Server first, then client. They work, which
in itself amazes me that it's so simple to create a network connection
like this! But my basic question is this: would this connection work if
the two computers (each running one of these scripts) were completely
unrelated to one another? My two are on a home network, but if I were to
run the server program and have a friend of mine (who lives somewhere
else) run the client program, would it still work?

-----
#!/usr/bin/env python

from socket import *
from time import ctime

HOST = '192.168.1.100'
PORT = 21567
BUFSIZ = 1024
ADDR = (HOST, PORT)

tcpSerSock = socket(AF_INET, SOCK_STREAM)
tcpSerSock.bind(ADDR)
tcpSerSock.listen(5)

while True:
print 'waiting for connection...'
tcpCliSock, addr = tcpSerSock.accept()
print '...connected from:', addr

while True:
data = tcpCliSock.recv(BUFSIZ)
if not data:
break
tcpCliSock.send('[%s] %s' % (ctime(), data))

tcpCliSock.close()

tcpSerSock.close()
-----

-----
#!/usr/bin/env python

from socket import *

HOST = '192.168.1.100'
PORT = 21567
BUFSIZ = 1024
ADDR = (HOST, PORT)

tcpCliSock = socket(AF_INET, SOCK_STREAM)
tcpCliSock.connect(ADDR)

while True:
data = raw_input('> ')
if not data:
break
tcpCliSock.send(data)
data = tcpCliSock.recv(BUFSIZ)
if not data:
break
print data

tcpCliSock.close()
-----

 

[John Salerno]

-----
#!/usr/bin/env python

from socket import *
from time import ctime

HOST = '192.168.1.100'

-----
#!/usr/bin/env python

from socket import *

HOST = '192.168.1.100'

A question about this. Is the "HOST" referring to the IP address of the
server computer in both of these cases? Because when I ran the program
and got to the part where it says "connected from:" on the server side,
it shows this same IP address. Shouldn't it be something different,
since the requests are coming from a different computer than the server
computer?

 

[John Salerno]

Works fine for me. When I run the client program on a machine
different than the server program, the server program prints
out "connected from:" and then the client machine's IP address.

Hmm, so could the reason that the client request is shown to be coming
from the same IP address as the server machine be that they are on the
same home network?

I guess to truly test my question, I need to have two computers that are
completely "unrelated" to one another -- meaning they are in no way
connected via any type of network prior to running these scripts.

 

[John Salerno]

That depends on your definition of "unrelated."

Heh heh, you mean that wasn't specific enough!?

I just mean completely unconnected in any possible way, network or
otherwise.

Yes, if the routers/firewalls/PCs were set up properly and if
you changed the IP addresses in the programs appropriately.

Ok, that's basically what I was curious about. Since my two computers
are already on a network, I couldn't be positive that this wasn't
allowing them to connect, rather than the two client/server scripts.

 

[John Salerno]

Is there any possibility you are confusing a Windows Workgroup or
Domain in this... (Assuming anyone still runs such) Or other Windows
convenience features to automatically detect computers in a local area
network and display them in "network neighborhood".

What I have is a desktop PC connected via ethernet cable to my cable
modem. I also use a router and my laptop uses a wireless connection.
This alone, of course, doesn't connect the computers, AFAIK. It's just
an internet connection.

What I did next was go to My Network Places > Set up a home or small
office network, and follow the wizard through the steps that would allow
me to share files and folders between the two computers. It's possible
I'm using the wrong terminology when I say this is a "home network,"
because all it is is the two computers being able to access each other's
hard drive.

 

[John Salerno]

If the two computers are in no way connected via any type of
network, then the two programs won't be able to talk to each
other.

The programs can't create a network, they can only use one that
already exists.

But isn't that the point of the program, to create a network between the
two computers? Isn't that what the host and port are used for, to open a
connection?

(Just to clarify, when I say "in no way connected", I don't mean not
connected to the internet in general. I know they need access to the
internet for any kind of networking program to work at all.)

 

[Lie]

But isn't that the point of the program, to create a network between the
two computers? Isn't that what the host and port are used for, to open a
connection?

No, you don't create a network between the two computers, the OS did,
your program just instruct it to create it and tell the OS to send
some data to it.

I can see that you don't have a clear idea of networking (I'm not a
network expert either, but I know enough). It's basically like this:
networking is arranged in layers, the lowest layer is the hardware,
the middle-man is the Operating System, and the highest level is your
program. The higher layer works on top of the lower layer, so the
lower layer must first be able to connect before the higher layer can
work. The lowest two layer is the hardware: the cable and the low-
level microcontroller. The cable (or in a wireless network... the
antenna) must be able to reach each other (the cable is connected to
another hardware, the antenna is in range of each other) before the
microcontroller can do anything. The same logic applies, before your
program -- the highest layer -- can do anything, the OS (which handles
layer 3 and 4) must be able to connect to the other computer first.
The easiest (and the most common) way to test whether two computers
can connect to each other is by pinging the other computer, if your
computer can ping the other computer (ping itself lies on the
application layer), any properly written program can connect to the
other computer (unless if there is firewall involved that may gives
some rules on how the two computers may connect).

(Just to clarify, when I say "in no way connected", I don't mean not
connected to the internet in general. I know they need access to the
internet for any kind of networking program to work at all.)

No, they don't need to be connected to the internet for the program to
work at all, they may be in the same local network that isn't
connected to the internet. The basic requirement is, there is a cable
(or for a wireless... well, you get the point) that connects the two
computers, either directly using PC-PC LAN cable, or indirectly
through the same home router, or even more indirectly through the same
"internet" router. Problem is, most home router have firewalls that by
default (and by security requirement) makes connecting two computers
from the internet a little bit harder and different than connecting to
each other from a local network (how and why, has been explained by
Dennis).

 

[Lie]

Let me see if this question even makes sense...I'm reading Core Python
Programming and I jumped ahead to the more specific topics like network
programming. I plan to follow along with the example in that chapter and
create a socket connection between my desktop and laptop.

However, these two computers are already connected on my home network
(using the Windows Network Setup Wizard), so I was wondering if this
will have any effect on what I might try to do with Python. In other
words, if the program I write actually works and allows the two
computers to speak to each other, will that be a result purely of the
program, or will it have anything to do with the fact that they are
already on a home network together? (i.e. there's another variable in play?)

Thanks.

The Windows Network Wizard is a poor abstraction to set up layer 3 and
4 (the TCP/IP and lower) and layer 5 (the file sharing). You don't
need to run this wizard if you've set up your TCP/IP and lower
correctly manually (which, according to me, is easier than using the
wizard). In a normal situation, you shouldn't need to worry about
setting up the layer 3 and 4, you can assume that this two already set
up.

Some problem lies when connecting two computers through internet, such
as you may have to use external IP address or set up port forwarding
on the server-side. This is due to the use of 192.168.xxx.xxx as
inside-LAN IP address instead of letting each device on the whole
world has their own IP address.

 

[Lie]

Let me see if this question even makes sense...I'm reading Core Python
Programming and I jumped ahead to the more specific topics like network
programming. I plan to follow along with the example in that chapter and
create a socket connection between my desktop and laptop.

However, these two computers are already connected on my home network
(using the Windows Network Setup Wizard), so I was wondering if this
will have any effect on what I might try to do with Python. In other
words, if the program I write actually works and allows the two
computers to speak to each other, will that be a result purely of the
program, or will it have anything to do with the fact that they are
already on a home network together? (i.e. there's another variable in play?)

Thanks.

The Windows Network Wizard is a poor abstraction to set up layer 3 and
4 (the TCP/IP and lower) and layer 5 (the file sharing). You don't
need to run this wizard if you've set up your TCP/IP and lower
correctly manually (which, according to me, is easier than using the
wizard). In a normal situation, you shouldn't need to worry about
setting up the layer 3 and 4, you can assume that this two already set
up.

Some problem lies when connecting two computers through internet, such
as you may have to use external IP address or set up port forwarding
on the server-side. This is due to the use of 192.168.xxx.xxx as
inside-LAN IP address instead of letting each device on the whole
world has their own IP address.

 

[John Salerno]

The network protocols form a layered stack. The bottom of the stack
is the physical connection: coax (now rare), twisted-pair (cat-5/cat-6
cable with rectangular plugs on the end), fiber optic... etc. At some
level above that is the part that translates data packets (containing IP
or IPX or other addressing scheme) to a data packet with the
MAC/hardware address of the destination connection -- both IP and IPX
could be running over the same cable without conflicts. Above that is
the part that handles, say, TCP or UDP -- this is the part that detects
TCP missed packets from a connection. Somewhere above that layer is
where things like FTP, SMTP, POP3, Telnet, HTTP, etc. live.

Geez, this network programming stuff is complicated, yet at the same
time very interesting and, well, not all *that* complicated! I guess it
helps to keep reading this stuff over and over, too. I just read the
section on socket programming in Programming Python, which also
discussed these layers and such.

I don't know why, but I find it all very interesting! I think one reason
is because this is sort of a "coming together" of everything I've ever
known/heard/read about the internet, but I never stopped to put it all
together until now.