Inconsistent behavior telnet to socket

[skolnick]

Over in 'Advanced Development' I came up dry trying to generate a scrolling status window in HTML/JavaScript, so I'm writing an applet to connect back to the server over a socket and get status information from a daemon.

I wrote a little perl program that camps on a socket and sends and receives (code follows); the intent was just to give me a simple, known function to test the applet against.

It runs and works okay, but I am getting an anomolous behavior I haven't figured out. When I telnet to the program from either Linux or Solaris ("telnet <i>domain</i> 33445") it behaves the way I expect (keeps taking input until I hit enter). When I telnet using the built-in Windows telnet it treats every character as if it was followed by a newline, yet the Windows telnet works fine in every other application (okay its braindead, it still works).

Ideas?



#!/usr/bin/perl -w

# Make a socket server
# listen on a high number port (say 33445)
# when connected to, send something
# listen for input:
# 1. quit - exit gracefully
# 2. send - resend "something" (not implemented)
# 3. disc - disconnect TCP connection (not implemented)

use IO::Socket;

my $SERVER_PORT = 33445;
my $time_to_die = "no";
my $time_to_disc = "no"; # not used
my $client;
my $flags;
my $len = 1024;

print "Open socket server ... ";
my $server = IO::Socket::INET->new(LocalPort => $SERVER_PORT,
Type => SOCK_STREAM, Reuse => 1, Listen => 10 )
or die "Couldn't be a tcp server on port $SERVER_PORT: $@, $!\n";
print "[ OK ]\n";

print "Connect ... ";
while ( $client = $server->accept() ) {
print "[ OK ]\n";
while ( !($time_to_die =~ /quit/) ) {
$client->send("Hello from the socket server!\n\r")
or die "Couldn't send: $!\n";
$client->recv($time_to_die, $len)
or die "Couldn't read: $!\n";
print "$time_to_die \n\r";
}
close( $server ) or die "Couldn't close socket! $@,$!\n";
print "Done!\n\n";
}

[skolnick]

This appears to be a difference in buffering approach. Other demands have prevented me from finishing the applet yet, but I did track down the reason the two telnet clients "worked differently."

It seems that telnet on Linux and Solaris both buffer user input until you hit return (or presumably when the buffer fills to some level -- didn't test). Windows telnet client on the other hand sends each character as soon as the user types it.

So my test socket server now buffers on its end until it gets a line terminator.

dave

[Arthur]

Not directly related to your question, but what I would like to know; is it allowed to run a server like this?

[skolnick]

Presumably you mean, is it allowed to run a server like this on FQ?

Dunno. Terra? Deb?

In my case, it doesn't make any difference, since (aside from an incidental test or two), I won't be deploying this on FQ. I asked here because there are smart folks here who answer fast, and I figured if no one answered within a day or so then no one had an answer.

In principal it isn't different from a cron job or some background task as long as the load is light. However it does expose an external interface that FQ doesn't have in their baseline, and potentially (depending on the quality of my code) a vulnerability. Hard to believe it would affect anyone but me given the security sandbox we have to play in.

I think in the spirit of community, FQ/Terra/Deb are unlikely to worry about the occasional experiment (I start and stop the server from a command line and haven't even set it up as a real daemon--no fork) and I am unlikely to really deploy anything not clearly in the domain of the usual without checking first. <g>

dave

[Arthur]

Presumably you mean, is it allowed to run a server like this on FQ? That's what I meant, yes. I was just wondering. I don't think it's allowed, but the TOS (http://www.futurequest.net/Services/TOS/) is a bit unclear on this point. It would probably fall under the category Bots?

But, if you're not gonna run it on FQ, it's not even an issue.

[skolnick]

Well Arthur you certainly got me thinking. I read the TOS back when I signed up and have not looked at it since. In my head, I boiled it all down to "be a good neighbor" with a dash of "don't do dumb things." <g>

So I went and looked at the TOS and did some other research.
BOTS We currently do not allow bots of any kind to be operated on the FutureQuest servers. This includes IRC, IRC bots, proxies and anonymizers.I'm not sure this applies. If a bot is "a software tool for digging through data. You give a bot directions and it bring [sic] back answers." (www.botspot.com) Apparently, the term bot (short for robot) is also applied to agents, particularly intelligent agents. Applications include data mining and web crawling. Referring to applications like IRC seems like a stretch from a semantic point of view. It seems to me that the spirit of that paragraph in the TOS is much broader than the choice of words would indicate. Subject to clarification from the powers that be <g>, I interpret the clause as meaning: "We currently do not allow servers or other daemons with external APIs or other interfaces to be operated on the FutureQuest servers. This includes but is not limited to IRC, IRC bots, proxies, and anonymizers. It does not include scripts or programs run as web cgi applications that may incorporate an external interface for the duration of a web session."

If that is an accurate interpretation, then the scripts clause would apply to my application (if I were planning to deploy it here):
Scripts Each account comes with its own cgi-bin in addition to the community cgi-bin. You are free to use any scripts you wish, however we reserve the right to disable any script that effects normal server operation. Scripts that are commonly known for causing server disruption include: cgi-based chat scripts, auctions, and banner exchanges. Scripts should be run from within your cgi-bin at all times. FutureQuest does allow an override for scripts that are not able to run from within the cgi-bin however FutureQuest does reserve the right to disable any scripts that are not running from with the cgi-bin if normal operations are being affected.
The ultimate functionality of what I am building (which might in fact come in handy some day on one of my web sites in particular) is best illustrated as follows:
[list=1]
Web server sends web page to user, spawns cgi process that forks socket server with unique port number.
'Object' or 'Applet' element in web page causes Java applet to download
Applet starts running, and connects to server using a socket connection over port above
Streaming data pushed to user, displayed in applet
Socket server dies when socket connection is broken
[/list=1]
This isn't particularly different from the way that streaming media works. Of course, in the end, there is always:
Server Abuse: Any attempts to undermine or cause harm to a server or any of the contents on the server is strictly prohibited. I hope Terra or Deb weigh in with their actual intent.

Regards, dave

[Terra]

I will touch on one area...

A telnet (or any remote terminal/console) application, whether short or long term, would be hunted down and terminated...

The main problem is that the script is already 'authenticated', and if some cracker finds it - then they have just landed command line access with minimal effort...

This class of daemon/process is strictly forbidden and should be added to our TOS using the basis of 'pty' connections and/or 'shell' connections...

"We currently do not allow servers or other daemons with external APIs or other interfaces to be operated on the FutureQuest servers. This includes but is not limited to IRC, IRC bots, proxies, and anonymizers. It does not include scripts or programs run as web cgi applications that may incorporate an external interface for the duration of a web session."
I like the wording you derived above, and will discuss borrowing it (with your permission of course)...

The problem with clauses like this, is that it would end up 10+ pages long if we had to itemize everything... It is even more difficult to say what we will allow, then what we will deny - hence it being generic in nature...

--
Terra
--Famous last words, "But I'm the only one that has access to it"--
FutureQuest

[skolnick]

Originally posted by Terra:
I will touch on one area...

A telnet (or any remote terminal/console) application, whether short or long term, would be hunted down and terminated...

Got that right. Telnet is in fact an example of the kind of thing I was trying to generalize in my interpretation of your "bots" clause. It is only an example (thus "but not limited to") of applications like ftp, ssh, web servers, even ntp. Can you imagine someone deciding to run their own copy of Apache? Or put a Gnutella node up? Just about anything that is a real daemon should be looked at with some suspicion. Command line access, a buffer overflow vulnerability, or the potential to run arbitrary code are all risks that--even if restricted to the sandbox of an xdomain--can affect others on the same server. The technical term is "bad thing."
"We currently do not allow servers or other daemons with external APIs or other interfaces to be operated on the FutureQuest servers. This includes but is not limited to IRC, IRC bots, proxies, and anonymizers. It does not include scripts or programs run as web cgi applications that may incorporate an external interface for the duration of a web session."
I like the wording you derived above, and will discuss borrowing it (with your permission of course)...

You are welcome to use my words. I hereby grant you irrevocable, nonexclusive right to use my words above or any derivitive thereof. I disavow all personal responsibility for their use or interpretation. Application is at your initiative alone and does not constitute the practice of law on my part. IANAL. <grin>

The problem with clauses like this, is that it would end up 10+ pages long if we had to itemize everything... It is even more difficult to say what we will allow, then what we will deny - hence it being generic in nature...
--
Terra
--Famous last words, "But I'm the only one that has access to it"--
FutureQuest
I agree. Generalized clauses are the only reasonable approach, because some armchair lawyer will find something that isn't on the 10 page list that still manages to give you galloping grief. Wouldn't it be nice if we could just have simple guidance like:
[list=1]
Don't do dumb things
If you do something dumb, don't do it again
If you do it again, refer to rule #1
[/list=1]

dave

Famous words right before the last words: "But Momma, we only did it once!"