Re: Trouble with sockets

Is your machine really called 'foo' and is this hostname resolved correctly to an IP-address belowing to your machine?

If I try your code on my machine (replacing 'foo' with 'localhost') it runs fine. Maybe you should try IP-addresses instead of hostnames. If you use a hostname, a machine will always try to resolve this to an IP-adress before it uses it (using DNS or another resolving mechanism), it's just one more step that can go wrong.

Hope this helps

Comment on Re: Trouble with sockets

Replies are listed 'Best First'.
Re^2: Trouble with sockets by sweetblood (Prior) on Jun 21, 2004 at 14:57 UTC
The machine name is correct, though per your suggestion I did try LocalHost in the server script and IP in my client script. Unfortunetly, I got the same results, 'Could not create socket: Connection refused' and I still do not see the connection doing 'netstat -a'. Thanks anyway! Sweetblood	[reply]
Re^3: Trouble with sockets by eXile (Priest) on Jun 21, 2004 at 15:32 UTC
mmm, maybe my post was a bit confusing. When I tried 'localhost ' on my own machine, I did that because my machine's name is not 'foo'. You better put the same IP-address in both scripts. If you put 'localhost' in the 'LocalHost' hash-key to build a new socket this socket will not be accessible from other machines on the network (under normal circumstances). But even with `LocalHost => 'localhost'` in your script I'd at least expect you to see a listening port when you do a 'netstat -a'. Maybe it's better to do 'netstat -an' so your TCP and UDP portnumers are not translated to servicenames. Another way to see if you've got a listening TCP port is to use telnet to connect to this service. For instance to check a connection on TCP port 1800 on host 1.1.1.1: `telnet 1.1.1.1 1800` [download] This will give you either a (useless) connection or a connection refused.	[reply] [d/l] [select]