Q: (1)TCP TCL server, and (2) future Tcl question.
Bob Jamison
Does anyone know of an existing extension to Tcl which listens
on a TCP port, and gives an incoming connection an interpreter
session? In other words, redirects the interpreter's stdin/stdout
over the TCP socket...
I could probably do it myself, but why reinvent the wheel?
This would probably be severely limited in its terminal emulation
capabilities, but this is OK. I want a machine-machine interface
for a scripted application (unnamed, commercial, not ours) which has no
IPC capabilities, but might be able to open a pipe to a telnet-like program.
Thus the value of having an interpreter on the other side, much like a
Postscript printer.
Of course I can 'rsh' to host:tclsh, but that's a bit on the kludgey,
ugly side, and not portable to MSW/Mac.
I realize that this has the potential for being a massive security hole,
but, hey, no problem, I program for a living.
2. Future TCL question
Another question: will sockets be native to the core of Tcl in the
future? I already have a Wish with my rendition of tcpconnect in it, but it
would be nice for the "unmodified" wish, the /usr/local/bin/wish copy,
to have it. It would also be good to know that a script that I give to
someone will run, without having to know their configuration or supplying
an extended wish/tclsh.
Sockets on UNIX are a given, all future MSWindows will
have a Winsock or Winsock-like kernel, and I believe Mr. Johnson
is using GUSI on the Mac. A machine-independent (as far as script
goes) set of socket functions, and mapping read/write to file streams,
would be, for want of a better term, cool. This would surely support
the phrase, "the scripting language of the Internet." Perl uses them,
and Perl network scripts are ubiquitous.
Thanks!
finally, on another note....
A Personal Observation: (speech)
This is a very nice newsgroup. There are a lot groups that have
a lot of requests for information and software, but this one has a
very good response rate, a lot of contributions, and a spirit of giving. I
have actually found myself supplying code and suggestions occasionally, believe
it or not. This is not a credit to me, but to the good
atmosphere provided here. This cooperation and collaboration is the
kind of stuff which has made the Internet great; not Netscape, not AOL.
A lot of people have the impression nowadays that when they join
the Internet, they are buying its services. Wrong. You cannot buy
good people. Helping and sharing are the foundation to the Net, and should
be encouraged and nurtured.
To Whom It May Concern: good work!
(speech over)
--
===============================================================
= Bob Jamison 713-244-5769 = rjam...@gothamcity.jsc.nasa.gov =
===============================================================
Jacob Y. Levy
which will work across all sources/sinks of IO like files, sockets, named
pipes and whatever else there is out there that will need to be supported.
With a clean interface between the generic IO level and the device-type
specific function, and with dynamic loading support, its also going to be
very easy to plug in your new kind of IO functionality if it's not supported.
I've tested it already with file-based IO and Brent Welch and myself are
going to be testing it with sockets soon.
--JYL
In article <43chfj$e...@popeye.jsc.nasa.gov>, rjam...@gothamcity.jsc.nasa.gov
says...
Jacob Y. Levy
supported and user-supplied IO mechanisms. You'll be able to do gets from
a socket, from a pipe, from a file, from a named pipe, etc. etc.
Another thing we're doing is to make this IO subsystem the best asynchronous
IO system available today. Thus you'll be able to do asynchronous IO across
all IO sources/sinks. Also, asynchronous flush and asynchronous close will
be supported to allow Tcl to be used to write extremely efficient (high
throughput) servers. Async flush means that a flush is requested but it
returns immediately and does not wait for the actual data flush. Async close
means that the device is no longer available from Tcl level but if there
is data still to be written out it happens in the background while Tcl can
continue computing. These two mechanisms will allow Tcl to serve a much
larger number of requests (e.g. http connections) than possible with the
current synchronous behavior of today's http servers. Of course all of this
will work across all three supported platforms (X11, Windows and Mac). As
I said before it's likely that all of this will show up in Tcl 7.5.
--JYL
In article <43fv86$a...@shellx.best.com>, j...@best.com says...
Reinhard A. Hamid
>1. Tcl Server Question
>
>Does anyone know of an existing extension to Tcl which listens
>on a TCP port, and gives an incoming connection an interpreter
>session? In other words, redirects the interpreter's stdin/stdout
>over the TCP socket...
>
>I could probably do it myself, but why reinvent the wheel?
>
I would like to know, how you can do it directly in tcl, too. (Please inform
me, if you have the solution.
On a unix maschine you can register your tcl programm in the
/etc/services and /etc/inetd.conf
Whenever a connection comes in, inetd launches your programm (using stdin and
stdout). This could be a TCL program too.
Regards Reinhard
Bob Jamison
on a TCL server:
Here is what I have in mind. I have used the following code for
a couple of projects already. This uses the BSD model to listen on
a socket, and to run a server function on an incoming connection:
===========================================
/*Server cnnections */
/*Sockets that wait for a connection */
/*These sockets use sck_readfrom() and sck_writeto() */
int sck_passive(int port,int type) /**/
{
int s; /*New socket */
struct sockaddr_in sin; /*IP/Port storage */
sck_trace("sck_passive");
memset(&sin,0,sizeof(sin));
sin.sin_family=AF_INET;
sin.sin_addr.s_addr=INADDR_ANY; /*Means I will take anyone*/
sin.sin_port=htons(port);
s=socket(PF_INET,type,0);/*type=SOCK_DGRAM or SOCK_STREAM*/
if (s<0)
{
sck_trace("Cannot create socket");
return FALSE;
}
if (bind(s,(struct sockaddr *)&sin,sizeof(struct sockaddr))<0)
{
sck_trace("Cannot bind to IP and port");
return FALSE;
}
if (type==SOCK_STREAM)
{
if (listen(s,2)<0)
{
sck_trace("Cannot listen to port");
return FALSE;
}
}
return s;
}
/*dofunc is the function to run on an incoming socket*/
/*It will be called as:
int retval;
retval = dofunc(socket);
*/
int sck_serve(int port,int type,void *dofunc) /**/
{
int msock,ssock; /*Master, slave sockets */
struct sockaddr_in sin,tsin; /*IP/Port storage */
int alen; /*Client's address length */
int KeepGoing;
int (*func)(int); /*Function to call */
sck_trace("sck_serve");
msock=sck_passive(port,type); /*Set up socket */
if (!msock) /*OK? */
return FALSE;
for (KeepGoing=TRUE;KeepGoing;)
{
memcpy(&tsin,&sin,sizeof(sin));
ssock=accept(msock,(struct sockaddr *)&tsin,&alen);
if (ssock<0)
{
sck_trace(" Bad incoming connection");
}
else if (dofunc)
{
func=dofunc;
(*func)(ssock); /*Call the user function*/
}
#ifdef UNIX
close(ssock);
#endif
#ifdef MSW
closesocket(ssock);
#endif
}
return TRUE;
}
===========================================
So for instance, if there is one of my functions, db_query(),
I would call this with something like:
ret = sck_serve(8080,TCP,dofunc);
For TCL, dofunc() could run the TCL interpreter with ssock
replacing stdin/stdout. For more than one, the
if (fork()==0)
construct could be used to spawn off child processes. This code
snippet does not use this, as my C source, socket.c, runs on
both UNIX and Winsock (single process).
As far as security goes, access privileges belong to whatever
process runs the sck_serve() function.
Again, many thanks to all who have answered my posting.
--
==============================================================
= Bob Jamison 244-5769 = rjam...@gothamcity.jsc.nasa.gov =
==============================================================
Bob Jamison
Making I/O generic, the way UNIX blurs the distinction
between streams, files, pipes, etc, sounds excellent.
I have been a UNIX programmer for years, which looks good
on a resume, but the PC/Mac world, which sounds easier,
is actually a nightmare to program in some areas.
I am impressed by some of the network applications I have
seen on those platforms, given their limitations.
There needs to be a deeper embedding of the network stack
in Windows and Mac. Most of the fixes I have seen to make
streams-like programming available on PC/Mac use layers
of C, or define C++ classes to hide low-level differences
between OS's. What they need are deeper roots; namely,
their drivers need to be part of the kernel, low enough
that that top of the stack, the socket, is at or below the level
of the file driver. Win 95's new stack, and Mac 8.0's OpenTransport are
heartening.
Currently, Winsock and MacTCP have been only loosely bound
to their respective OS's and are not actually parts of them.
Until you run them, they are just files.
One sticking point for me are Winsock's slight differences
from straight file i/o. The specifications for the
Winsock API have various intentional discrepancies from UNIX.
Here are a few:
o As far as I know, read() and write() do not work on a socket;
recv() and send() do the job.
o Closesocket() MUST be used instead of close().
o Since Winsock is not part of the DOS/Windows kernel, you
cannot be certain that a socket is unique from a file
identifier.
o errno.h's error numbers have equivalents, for the most part,
in winsock.h. THEY ARE NOT THE SAME, for the previous reason.
In other words, errno and perror() are not part of Winsock.
You need WSAGetLastError() for that.
A common bit of code I use, and have seen, is the one which checks
to see if new incoming information is available on a non-blocking
socket (from memory, pardon typos):
#ifdef UNIX
if (errno == EWOULDBLOCK) /* =WOULD= have blocked, if it were blocking*/
#endif
#ifdef MSWINDOWS
errno = WSAGetLastError(wsa);
if (errno == WSAEWOULDBLOCK)
#endif
Since the engineers at Sun are working on mapping disparate functionality
to a common model =anyway=, hiding these differences in C wrappings
would be wonderful for the user.
It would seem that line-at-a-time puts()/gets() interface would be easiest
to program, and is all our project would really need, anyway. We
don't need a user-friendly interface, just basic input/output that
can provide a client/server session.
Thanks again.
Bob Jamison
you probably answered my question. First chance I get, I'll
give your 'interp' a try, and let you know how it turned out.
Thank you very much.
Bob
Jacob Y. Levy
event and exception handling, interrupts, transient failures, buffering
and flushing *in the generic layer* so that applications written in Tcl
won't have to worry about all that stuff at all. All you have to do is
to open a device of the kind you want and gets/puts will "just work" on
it. That it's a nightmare is all the more reason to solve this problem
only once - in C - and then make the Tcl level enjoy relative freedom from
having to deal with the vagaries.
I've got a proof-of-concept implementation which is working on Solaris only
currently, and only with files, terminal I/O (stdin, stdout and stderr), and
pipes. Sockets will be done this week too, then it's time to try PC based
IO, then .... :) As I said before this is all likely to show up in one of
the following alpha releases of Tcl 7.5.
--JYL
In article <43kj4m$b...@popeye.jsc.nasa.gov>, rjam...@gothamcity.jsc.nasa.gov
says...