By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
440,812 Members | 875 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 440,812 IT Pros & Developers. It's quick & easy.

Creating a TCP/IP connection on already-networked computers

P: n/a
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.
Jun 27 '08 #1
Share this Question
Share on Google+
17 Replies


P: n/a
On 2008-06-14, John Salerno <jo******@gmailNOSPAM.comwrote:
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.
I don't know the example programs you're talking about, but
it's a pretty good bet that the example programs won't work if
the two computers can't reach each other using IP networking.
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?)
The two Python programs won't be able to communicate with each
other unless the two computers are already set up on network(s)
that allow the routing of IP packets between the two computers.
I presume that's what the "Network Setup Wizard" did (set up IP
networking), but I don't really do windows (I especially don't
do "Wizards" if I can avoid it).

--
Grant Edwards grante Yow! Alright, you!!
at Imitate a WOUNDED SEAL
visi.com pleading for a PARKING
SPACE!!
Jun 27 '08 #2

P: n/a
John Salerno wrote:
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()
-----
Jun 27 '08 #3

P: n/a
John Salerno wrote:
-----
#!/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?
Jun 27 '08 #4

P: n/a
On 2008-06-14, John Salerno <jo******@gmailNOSPAM.comwrote:
John Salerno wrote:
>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?
That depends on your definition of "unrelated."
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?
Yes, if the routers/firewalls/PCs were set up properly and if
you changed the IP addresses in the programs appropriately.

--
Grant Edwards grante Yow! I want the presidency
at so bad I can already taste
visi.com the hors d'oeuvres.
Jun 27 '08 #5

P: n/a
On 2008-06-14, John Salerno <jo******@gmailNOSPAM.comwrote:
John Salerno wrote:
>-----
#!/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?
Yes.
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.
Then you must have been either running the client program on
the same machine as the server program or you've got some sort
of NAT/port-forwarding going on.
Shouldn't it be something different, since the requests are
coming from a different computer than the server computer?
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.

--
Grant Edwards grante Yow! Maybe I should have
at asked for my Neutron Bomb
visi.com in PAISLEY --
Jun 27 '08 #6

P: n/a
Grant Edwards wrote:
>Shouldn't it be something different, since the requests are
coming from a different computer than the server computer?

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.
Jun 27 '08 #7

P: n/a
Grant Edwards wrote:
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.
>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?

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.
Jun 27 '08 #8

P: n/a
On 2008-06-14, John Salerno <jo******@gmailNOSPAM.comwrote:
Grant Edwards wrote:
>>Shouldn't it be something different, since the requests are
coming from a different computer than the server computer?

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?
No, not for the usual value of "on the same home network".
I've no idea how your home network is set up, so that's about
all I can say.
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.
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.

--
Grant Edwards grante Yow! I've got an IDEA!!
at Why don't I STARE at you
visi.com so HARD, you forget your
SOCIAL SECURITY NUMBER!!
Jun 27 '08 #9

P: n/a
On 2008-06-14, John Salerno <jo******@gmailNOSPAM.comwrote:
Grant Edwards wrote:
>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.
If they're completely unconnected in any possible way, then I
take that to mean that any communication between the two
computers is impossible.

--
Grant Edwards grante Yow! I demand IMPUNITY!
at
visi.com
Jun 27 '08 #10

P: n/a
Dennis Lee Bieber wrote:
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.
Jun 27 '08 #11

P: n/a
Grant Edwards wrote:
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.)
Jun 27 '08 #12

P: n/a
On 2008-06-15, John Salerno <jo******@gmailNOSPAM.comwrote:
>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.
That probably means that the computers are on a common subnet
and can communicate with each other using normal IP routing.
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.
"home network" is pretty much a meaningless term, so you can
use it however you want. My guess is that all the "wizard" did
was set up file and print sharing between two computers that
were already on the same network and could already talk to each
other. IOW, if both computers were able to access the internet
via a single cable modem before you ran the wizard, then it's
quite likely they could have communicated with each other as
well (using the two python programs or any other network aware
applications).

--
Grant Edwards grante Yow! I'm ZIPPY!! Are we
at having FUN yet??
visi.com
Jun 27 '08 #13

P: n/a
On 2008-06-15, John Salerno <jo******@gmailNOSPAM.comwrote:
Grant Edwards wrote:
>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?
No. For the two programs to work, the network must already
exist and be properly configured. In this seinse, a "network"
is a mechanism which programs can use to establish connections
with each other.
Isn't that what the host and port are used for, to open a
connection?
Yes, but a connection and a network aren't the same. When you
pick up the phone and dial it, a connection between your phone
and the phone your calling is set up. You dialing the phone
isn't creating a telephone phone network -- it's using the
existing telephone network to create a connection. In the case
of the telephones, the "network" is the wires, the central
office switches (and associated software), and the
interconnecting trunks. In your house, the "network" is the
wires and router and cable modem and network cards (and the
associated configuration data). Your "home network" may or may
not have a connection to the outside world.
(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, the two computers don't need to be connected to the
internet in general. You could set up a network that consists
entirely of those two computers and nothing else. Applications
on those two computers could still communication with each other.

--
Grant Edwards grante Yow! Why don't you
at ever enter and CONTESTS,
visi.com Marvin?? Don't you know
your own ZIPCODE?
Jun 27 '08 #14

P: n/a
Grant Edwards wrote:
"home network" is pretty much a meaningless term, so you can
use it however you want. My guess is that all the "wizard" did
was set up file and print sharing between two computers that
were already on the same network and could already talk to each
other.
Yes, you're right. AFAIK, that was the only effect of what I did.
IOW, if both computers were able to access the internet
via a single cable modem before you ran the wizard, then it's
quite likely they could have communicated with each other as
well (using the two python programs or any other network aware
applications).
So in the case of me trying this with a friend who lives far away, how
would these two scripts work if we wouldn't be on the same connection?
Jun 27 '08 #15

P: n/a
Lie
On Jun 15, 8:40*am, John Salerno <johnj...@gmailNOSPAM.comwrote:
Grant Edwards wrote:
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?
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).
Jun 27 '08 #16

P: n/a
On 2008-06-15, John Salerno <jo******@gmailNOSPAM.comwrote:
So in the case of me trying this with a friend who lives far
away, how would these two scripts work if we wouldn't be on
the same connection?
It depends on the way the two networks are set up. Here's a
fairly typical setup:
Machine1 ----+
192.168.0.100 | Router/Modem
+--------- ----------- The Internet
Machine2 | 192.168.0.1 A.B.C.D
192.168.0.101 ----+
The router/modem is generally set up to do NAT (network address
translation) firewalling. To everybody on "The Internet" your
computers both appear to have an IP address of A.B.C.D (the
numbers A,B,C,D are assigned by your ISP, and are unique on the
Internet). The 192.168.0.x numbers mean nothing to anybody not
on the same side of the router as your two machines.

The router will generally allow "outbound" connections but
not "inbound" connections: your computers can initiate
connections to machines on the internet, but machines on the
internet are not allowed to initiate connections to your
machines.

Let's assume that your friend has a similar setup:
Machine3 ----+
192.168.0.100 | Router/Modem
+--------- ----------- The Internet
Machine4 | 192.168.0.1 E.F.G.H
192.168.0.101 ----+

Again, the 192.168.0.x numbers mean nothing to anybody outside
your friend's house. To the rest of the world, your friend
only has the single, unique IP address of E.F.G.H.

Let's say you want to intiate a connection from Machine1 at
your house to port M on Machine4 at your friend's house. By
default, his router/modem probably won't allow that unless he
specifically configures it. To do that, he has to enable
"port forwarding" by configuring the router/modem so that
connection requests received from the internet side addressed
to E.F.G.H port N are forwarded to port 192.168.0.101 port M.
(M and N might be different, but don't have to be).

Your friend configures the server program to listen on
192.168.0.101 port M (on Machine4).

You configure the client program (on Machine1) to connect to
E.F.G.H port N. When the connection request from the client
program is received by your Router/Modem, it automatically
translates the source address from 192.168.0.100 to A.B.C.D and
then sends the request to E.F.G.H port N (which is your friend's
router/modem).

Your friend's router/modem looks in the port forwarding
configuration and sees that it should translates the
destination address from E.F.G.H port N to 192.168.0.101 port
M. It sends the translated request on to Machine4 where the
server program is listening. The program then accepts a
connection request (which is now from IP address A.B.C.D due to
the translation that was done by your router).

When the server program sends a packet from 192.168.0.101 to
A.B.C.D (after all, that's where it appears the request came
from), your friend's router modem translates the source address
from 192.168.0.101 to A.B.C.D. Your router/modem receives that
packet and looks at where it came from. The router/modem
remembers that it sent a connection request to there and also
remembers where the connection request came from originally, so
it translates the destination address from A.B.C.D to
192.168.0.100 and sends the packet back to the client machine
where the client program receives it.

I hope that made sense. NAT can be a little confusing.

--
Grant Edwards grante Yow! I'm EMOTIONAL
at now because I have
visi.com MERCHANDISING CLOUT!!
Jun 27 '08 #17

P: n/a
Dennis Lee Bieber wrote:
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.
Jun 27 '08 #18

This discussion thread is closed

Replies have been disabled for this discussion.