I had already created a qt program that listens on a specific port on my server. And it works fine. Now I want to create a simple ruby program to do the same. Right now I just have a simple test server using netcat which establishes a network socket and accepts UDP data (this is Ubuntu server by the way):
$ sudo nc -l 1720
Now I am just trying to listen on the port in Ruby:
# network.rb
require 'socket'
socket = UDPSocket.new
socket.bind('64.xxx.xx.xxx', 1720)
This right away raises this exception:
network.rb:4:in `bind': Cannot assign requested address - bind(2) (Errno::EADDRNOTAVAIL)
WHy is it saying the address is not available? All that is there is a netcat socket. The goal is that I will have UDP data coming in from GPRS devices to that port, and then I will have ruby sitting on my ubuntu server listening for that data, then decoding it, and storing it into a postgresql database.
You are making a server or client?
you used nc, so i guess you are making client.
server is bind
client is connect:
c = UDPSocket.new
c.connect("127.0.0.1", 1111)
"address is not available" usually as the port is used.
or you can ping the address fisrt to check if the address can be reached
I was getting the same error by running:
rails s -b 10.0.0.61
It turns out that my local IP wasn't 10.0.0.61 and this was causing the error.
Related
I want to add support for the PORT command to my FTP server. I'm reading RFC 959, but I can't figure out when it's safe to connect to the FTP client. For example, consider this sequence:
PORT 127,0,0,1,34,34
LIST
Does the FTP client start listening before issuing the PORT command, or after issuing the LIST command? Because if the server attempts to connect to the client immediately after receiving PORT, it might fail because the client might not have started listening yet.
What does the specification say? Can the server connect immediately, or should it wait until after it receives the command that will make use of the data connection?
The server shouldn't connect to the client until it gets a command that requests a data transfer, such as LIST or RETR. See section 7 of RFC 959, which shows a typical sequence of operations (RFC's didn't have the formal MUST/MAY/SHOULD specifications in those early days).
However, since the port used in the PORT command is typically an ephemeral port, the client needs to open a socket to get the OS to assign a port number. This implies that by the time the PORT command is sent, the port would have to be open. However, it's possible that it might not yet have called listen().
I have a client which is intended to connect to a server. For the client, the remote TCP port number is fixed(i.e. 102). I can NOT change it(while I can change the remote IP address). However, the TCP Port number the server is listening on is fixed as well(i.e. 1024) and I can NOT change it too. These two port numbers are different. I want to make the client connect to the server smoothly.
At the first, I had a idea that I setup a proxy listening on localhost:102 and the client connect to 127.0.0.1:102. Then this proxy redirect these TCP traffic to the real address RemoteServerIP:1024. But I found on my windows, there was already a process which is listening on 0.0.0.0:102 and I can NOT change its listening port. So this idea can NOT work.
Thank you very much.
if you cannot do it on the same windows machine running client, why not try to do it on another (linux maybe) machine?
I am trying to learn how to send TCP packets across the internet to another computer. So say, computer 1 sends data across the internet to computer 2 (using TCP). Assuming that both computer have port forwarding correctly set, how would I go about establishing a TCP connection between the two computers (in Ruby preferably)? I have it working on my LAN, but when I try over the internet, it doesn't seem to work.
My attempt (basically):
Computer 1:
server = TCPServer.new 32500
client = server.accept
Computer 2:
TCPSocket.new PUBLIC_IP_OF_COMPUTER_1, 32500
Problem is that TCPSocket never connects to TCPServer.
I read in the Ruby doc that TCPServer.new's syntax is
new(remote_host, remote_port, local_host=nil, local_port=nil)
What happens if I just leave local_host=nil and local_port=nil (rather than assign them the private IP and port 32500 number on Computer 1)?
If somebody could point me in the right direction, that's be great! I hope I my approach is at least somewhat correct.
You created a server which is listening only on the loopback Interface.
Try this out:
curl ifconfig.me
You will get your external IP address, how it is visible from outside, for example 123.123.123.123
server = TCPServer.new 2000
Now You have a server listening on port 2000
lsof -i :2000
for example:
ruby 37186 wopi 6u IPv4 0xcf0818acc2bdc38d 0t0 TCP *:callbook (LISTEN)
now connect from THE SAME machine to localhost
telnet localhost 2000
this works
telnet 123.123.123.123 2000 # substitute your real external IP address
this will not work
That is why You can't connect from outside.
Checkout how ngrep, netcat and tcpdump are working, invaluable tools for network debugging.
I would like to establish a connection between 2 computers using socket. For this purpose one of them is a server and this is the code I've write:
sock= TCPServer.open('localhost', 6666)
sock.accept
the client try to establish the connection:
client = TCPSocket.open(ip_server, 6666)
but is not working. I've notice scanning server's ports that the server does not open the port to the network, only works in local mode.
Any suggestion, thk in advance
I've used this code successfully. Server side:
serverSocket = TCPServer.new( "", port )
serverSocket.accept
and on the client
t = TCPSocket.new(server_ip, port.to_i)
However, recently I've started using the 'EventMachine' gem, which made handling sockets 10 times easier
It's already been said that the service is running in "Local Mode" using the loopback "localhost".
sock= TCPServer.open('localhost', 6666)
sock.accept
TCPServer is a handy interface for the underlying file descriptor. Frankly, it almost makes socket programming too easy.
Like what has already been said, 'localhost' is a loopback to 127.0.0.1. Therefore, your statement is equivalent to:
sock= TCPServer.open('127.0.0.1', 6666)
sock.accept
If you will be using the network connection on a local network, assuming the server has an assigned IP of 192.168.0.1, you can assign a local IP address to listen on:
sock= TCPServer.open('192.168.0.1', 6666)
sock.accept
For an open port, conceivably open to all, use:
sock= TCPServer.open(6666)
sock.accept
Remember that everything is a file – the connection you're making is reading and writing to the same file or series of files from two (or more) locations. It's important to control who might have access to those files, and to what extent.
Yes, and it allright so, because you said it should bind the server port to the interface of 'localhost' and this is 127.0.0.1 and is bind to your loopback interface and not to any real interface connecting to the realworld.
You should try
sock = TCPServer.new(6666)
sock.accept
It works in "local mode" because it listens on localhost wich is loopback address for the computer the server is launched in. The IP address of your server should be address your computer has on local network (something like 192.168.x.x).
I've been trying to get sqlplus to connect to Oracle from my OS X machine. I asked another question about it here.
One person suggested that I try telnet. Consulting the man page, I tried:
[ ethan#gir ~ ]$ telnet DBHOST:1521
Trying xxx.xxx.xxx.xxx...
telnet: connect to address xxx.xxx.xxx.xxx: Operation timed out
telnet: Unable to connect to remote host
Also...
[ ethan#gir ~ ]$ telnet DBHOST 1521
...with same result.
I'm not sure how to interpret these results. Seems like what you'd expect in any case. You wouldn't do this...
$ ssh some_mysql_host:3306
How is telnet to Oracle different?
Or maybe I didn't understand what they meant.
If anyone could help me understand how one uses telnet to test a connection to Oracle I would be grateful.
They're proposing use of telnet simply because it's one of the simplest TCP/IP clients and because it's installed almost everywhere. It's just an easy way to check from the command line whether you're actually able to make a TCP/IP connection to any particular service.
Also, on many of the ASCII based IP protocols it's straight forward to actually interact with the server to check its working by typing in commands and looking at the responses - I've done this numerous times myself with SMTP servers.
In your case, as you're getting a timeout, either the whole host is down, or the access to that particular host or service is being blocked by a firewall. If you can reach the server with a ping then the latter is more likely.
There's also an outside chance that your name resolution is actually taking you to the wrong host, but you should be able to confirm that by looking at the IP address that telnet said it was trying to connect to.
Another common response is "connection refused". That means that the host is up, but that there's no service running on the specified port.
Basically when you specify a port number e.g
Telnet myserver 1521
It will try to connect to the machine on that port. If you see any data returned or even a blank console then it has connected. If you receive an unable to connect message then the machine is not listening on that port or a firewall is blocking the connection.
Your attempt to telnet to dbhost 1521 getting 'unable to connect' with a timeout suggests that either your hostname resolution for 'dbhost' is giving you the wrong answer, or that host is offline, down or you have network problems.
If oracle was working, you'd get a connection. You wouldn't really be able to do anything with it, but it would confirm that oracle was up and listening.
Oracle instance is not connected from other systems, while it is connected from localhost, I think port is not opened and it is showing problem to telnet 1521 port from other system.
Why not do it the 'right' way? Telnetting to some arbitrary network port will not give you correct information, if the database and it's listener is working correctly.
Just install the oracle instantclient software and use the configuration wizard.