I'm currently starting a Tcl socket server like this:
socket -server Server 0
This lets the operating system pick an available port to start listening on. The question is that I don't want it to pick any port between 1025 and 64k, instead want to know if I can specify a range of ports? Something like this:
socket -server Server 40000-41000
And then the operating system would pick an available port between 40000 and 41000 for the server to listen on. Is there a way to do this? I can't find it in the Tcl API, but is there some nice API call way to do it rather than iterating through the port range until finding an available port?
The OS itself doesn't provide an API capable of doing that, and Tcl doesn't wrap one up for you as it is actually a pretty rare requirement. Conventionally, servers either listen on specific ports (so clients can know exactly what service to ask for; e.g., 21 for FTP, 22 for SSH, 25 for SMTP, 80 for HTTP, 161 for SNMP, 443 for HTTPS, 993 for secure IMAP) or the clients have some other way of being told what to ask for and genuinely any port will do (0 is the special “pick a card, any card” address). You can ask a Tcl server socket for what port it is actually using fconfigure:
set portNumber [lindex [fconfigure $socket -sockname] 2]
But to get a server socket on a port in a specific range? No API for that. We have to cook something ourselves:
for {set port 40000} {$port <= 41000} {incr port} {
if {![catch {
set sock [socket -server $yourHandler $port]
}]} then {
break
}
}
# If we failed...
if {![info exist sock]} {
error "No ports free in range 40k-41k"
}
This works because failing to bind the port will make the socket creation fail (neatly, catchably) and you can then try to bind the next port. It will take a while to scan over the port range, but it will work.
It's probably neater to wrap this up in a procedure. And Tcl 8.6's try construct will make the code a little less obscure:
proc portInRange {from to handler} {
for {set p $from} {$p <= $to} {incr p} {
try {
return [socket -server $handler $p]
} on error {} continue
}
error "No ports free in range $from-$to"
}
No, there's no API for that.
Generally servers listen on a specific port so that the clients can find the server. So such an API is not particularly useful.
Best to just write it yourself.
Related
I am developing a peer to peer call. I am using de.javawi.jstun.test .
I found this constructor in de.javawi.jstun.test.DiscoveryTest .
public DiscoveryTest(InetAddress sourceIaddress, int sourcePort, String stunServer, int stunServerPort) {
this.sourceIaddress = sourceIaddress;
this.sourcePort = sourcePort;
this.stunServer = stunServer;
this.stunServerPort = stunServerPort;
}
My question is What is the difference between the Source Port and the StunServerPort??
stunServerPort is the port the STUN server listens on for incoming binding requests. This is typically one of the standard STUN ports: 3478 or 3479.
sourcePort is the port the client behind a NAT has obtained locally to create a socket with. Most often, the client attempting to do P2P will ask the OS to randomly pick an available local port to send/receive from. You can probably pass 0 for sourcePort and let it pick the port for you as well. Or if you already have a socket, use the same port as your local, and DiscoveryTest will set the reuseaddr flag so it can have a socket co-exist.
I want to make 2 devices communicate via sockets.
I use this code for the client socket:
Socket socket = Gdx.net.newClientSocket(Net.Protocol.TCP, adress, 1337, socketHints);
(SocketHints: timeout = 4000)
I get a GdxRuntimeException each time this line is being executed. What is wrong with the socket?
Screenshot of stack trace
You get that message because the socket couldn't be opened.
Note the last line about the return in the API:
newClientSocket:
Socket newClientSocket(Net.Protocol protocol,
java.lang.String host,
int port,
SocketHints hints)
Creates a new TCP client socket that connects to the given host and port.
Parameters:
host - the host address
port - the port
hints - additional SocketHints used to create the socket. Input null to use the default setting provided by the system.
Returns:
GdxRuntimeException in case the socket couldn't be opened
Try doing some debugging to find out why you are getting this error.
Is the port already in use? Are you trying to open more than one connection on the same port? Is the server IP valid? Maybe something else is causing the issue?
I'm writing a short script to query domain names from their respective whois servers - while in most cases, while the TCP connection via port 43 seems to be working for most whois servers, the queries to whois.markmonitor.com seems to be failing with an odd error that says Invalid query.
Here's the barebones of what I'm using:
#!/usr/bin/perl
#whois.pl
use strict;
use IO::Socket;
my $domain_name = "google.com";
my $query_socket = new IO::Socket::INET(
PeerAddr => 'whois.iana.org',
PeerPort => 43,
Proto => 'tcp');
print $query_socket "$domain_name ";
print $query_socket "\n\r";
while(my $this_line = <$query_socket>) {
print $this_line;
}
close($query_socket);
As seen above, the whois server used is whois.iana.org; this also works as expected with whois.internic.net as well. Only in the case of whois.markmonitor.com, the following error is seen:
$ perl whois.pl
Invalid query
Could someone help shed more light on how can I perhaps get a more verbose output to check if there are any errors in the query that is being made to the server?
As an added test, a normal connection via telnet seems to be working as expected as seen below:
$ telnet whois.markmonitor.com 43
Trying 64.124.14.21...
Connected to whois.markmonitor.com.
Escape character is '^]'.
google.com
Domain Name: google.com
Registry Domain ID: 2138514_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.markmonitor.com
Registrar URL: http://www.markmonitor.com
Updated Date: 2015-06-12T10:38:52-0700
Creation Date: 1997-09-15T00:00:00-0700
......<output truncated>......
which leads me to believe that the actual connections to the server via port 43 are being accepted on the server's side.
As artistoex notes - it's because there's a space in your domain name.
Change your print line to:
print {$query_socket} "$domain_name\n";
(Note - the curly braces are for style reasons and can be omitted - I prefer them to make clear this is a file handle)
Per RFC3912 the client is expected to communicate like that in whois protocol: "All requests are terminated with ASCII CR and then ASCII LF"
So in your code, instead of "\n\r" please use "\r\n". And remove the extra space like written in other replies.
Note however that whoisis not a well defined structured protocol: do not expect all whois servers to work in the same way nor to adhere to some kind of standards. You will find a lot of strange cases...
The laptops in our company go to the network either about LAN (workplace) or about WLAN (conference room). Depending on how they go to the net, they get from DHCP different IPs.
Certain Perl application on a server, copies files from the client (e.g. laptop above) with Net::FTP. The piece of code looks like this:
# don't wait for ftp-timeout if the host is not reachable
my $alive = Net::Ping::External(host => $clnt_host);
if ($alive) {
$ftp = Net::FTP->new($clnt_host, Debug => 0, Timeout => 200)
or return "Cannot connect to $clnt_host: $#\n";
....
....
}
else {
dbgout(1, "Host $clnt_host unreachable.\n");
$st = "'FTPGETFAILED'";
return ($st);
}
Sometimes the code above doesn't work: Net::Ping::External() returns "alive", but Net::FTP->new() gets a "timeout".
Obviously "FTP" and "ping" resolve the hostname differently.
On the OS ping reslove as follows:
C:\Users\converter>ping -n 1 lap314-034
Ping wird ausgeführt für lap314-034.domain.de [10.140.12.110] mit 32 Bytes Daten:
Antwort von 10.140.12.110: Bytes=32 Zeit=2ms TTL=127
However, "nslookup" returns 2 possibilities:
C:\Users\converter>nslookup lap314-034
Server: domaincontroller.domain.de
Address: 123.123.123.123
Name: lap314-034.domain.de
Addresses: 10.192.3.145
10.140.12.110
The not active IP address is delivered from nslookup at the first place back.
I suppose that Net::FTP also uses this address to connect to the client.
How can I "convince" FTP to use the active DNS entry for the connection?
=============================================================
Thanks for your answers. I followed your suggestions. The solution bases on: http://code.activestate.com/lists/perl-win32-users/32624/
#------------------------------------------------------------------
sub getActiveIP {
#------------------------------------------------------------------
my $hostname = shift;
my $host = (gethostbyname ($hostname))[0] or return undef;
my #addr = gethostbyname ($host);
# delete the first 4 array elements
splice #addr, 0, 4;
foreach (#addr) {
my $IPstr = sprintf ("%s", &inet_ntoa ($_));
my $alive = ping(host => $IPstr);
if ($alive) {
return $IPstr;
}
}
return undef;
}
Nevertheless, I believe that a widespread Perl-library should not make such surprises to the user.
How can I "convince" FTP to use the active DNS entry for the connection?
There is no good way to let Net::FTP decide it.
Instead you should determine it outside of Net::FTP and then use the usable IP address instead of the hostname in Net::FTP.
Maybe you would be able to use only Net::FTP with the new versions (Net::FTP > 3.0) which can use IO::Socket::IP instead of IO::Socket::INET as the underlying module. This module can try all the IP addresses returned for a hostname until it gets a successful connection. But these retries will be done for every connection, that is the control connection and every data transfer. Since the connection to the inactive host only fails after some timeout everything will just be horribly slow.
The solution seems obvious: Get the IP addresses, ping them, figure out which one is live, and use the IP address instead of host name in the Net::FTP constructor.
I have a simple Python server which can handle multiple clients:
import select
import socket
import sys
host = ''
port = 50000
backlog = 5
size = 1024
server = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
server.bind((host,port))
server.listen(backlog)
input = [server,sys.stdin]
running = 1
while running:
inputready,outputready,exceptready = select.select(input,[],[])
for s in inputready:
if s == server:
# handle the server socket
client, address = server.accept()
input.append(client)
elif s == sys.stdin:
# handle standard input
junk = sys.stdin.readline()
running = 0
else:
# handle all other sockets
data = s.recv(size)
if data:
s.send(data)
else:
s.close()
input.remove(s)
server.close()
One client connects to it and they can communicate. I have a third box from where I am sending a RST signal to the server (using Scapy). The TCP state diagram does not say if an endpoint is supposed to try to recover a connection when it sees a RESET. Is there any way I can force the server to recover the connection? (I want it to send back a SYN so that it gets connected to the third client)
Your question doesn't make much sense. TCP just doesn't work like that.
Re "The TCP state diagram does not say if an endpoint is supposed to try to recover a connection when it sees a RESET": RFC 793 #3.4 explicitly says "If the receiver was in any other state [than LISTEN or SYN-RECEIVED], it aborts the connection and advises the user and goes to the CLOSED state.".
An RST won't disturb a connection unless it arrives over that connection. I guess you could plausibly forge one, but you would have to know the current TCP sequence number, and you can't get that from within either of the peers, let alone a third host.
If you succeeded somehow, the connection would then be dead, finished, kaput. Can't see the point of that either.
I can't attach any meaning to your requirement for the server to send a SYN to the third host, in response to an RST from the third host, that has been made to appear as though it came from the second host. TCP just doesn't work anything like this either.
If you want the server to connect to the third host it will just have to call connect() like everybody else. In which case it becomes a client, of course.