Nuno Carvalho wrote:

> > Also, note that tputs() uses the function which is provided as the
> > third argument to actually send each character. Instead of using
> > putchar(), write your own function which uses fputc to write the
> > character to the socket.
> 
>      int tputs(const char *str, int affcnt, int (*putc)(int));
> 
>  Could you explain me better how to do it ?
>  
>   1. third argument [int (*putc)(int)] of tputs() only send one argument
> to those argument! How can I also send client's descriptor ?

        int my_putc(int c)
        {
                fputc(c, socket_fp);
        }

>   2. 
>            int fputc(int c, FILE *stream);
> 
>       Second argument of fputc() is a (FILE *) and the client's
> descriptor it's an integer (int). Maybe try write or send !?

        FILE *socket_fp = fdopen(socket_fd, "r+");

> > >  setupterm( "vt100", client_fd, (int*)0 ); 
> > 
> > This will only work if the client happens to use the same escape
> > sequences as a vt100.
> 
>   I had changed from "vt100" to (char*)0   !! It's better, rigth !?

Right, but you need to ensure that TERM is set correctly. If your
program was invoked by telnetd, then TERM would already be set to the
value passed by the telnet client.

> > The bottom line is that you are trying to do too many things yourself. 
>  
>  I don't know. My project it's for an Introduction to Networking ...
>  I need use socket(), accept(), listen(), etc ... 

Then you probably shouldn't be dealing with the specifics of either
the telnet protocol, or with curses.

The `Unix way' is to have:

A program (inetd) which handles the accept() and fork() loop for
multiple services.

Another program (in.telnetd) which handles the telnet protocol, which
allows programs to be run in an environment similar to being run from
a serial terminal.

Application programs which can run on a serial terminal. These could
be run on the Linux console, xterm/rxvt, via telnet, a dial-in
connection from e.g. telix, minicom etc, or a hardware serial
terminal.

> > You should be using inetd to handle the connection, and in.telnetd to
> > handle the telnet protocol. Your program should just assume that there
> > is a terminal connected to stdin/stdout.
>  
>  What do you mean by handle connections using inetd !? I'm using
> telnet/tcp/23 . I need to use the protocol's stack TCP/IP!
>  The same question about in.telnetd !

The way that a telnet login is handled is that /etc/inetd.conf
contains a line like:

telnet  stream  tcp     nowait  root    /usr/sbin/in.telnetd    in.telnetd

This causes inetd to listen on the telnet port (TCP/23), and to
execute the in.telnetd program whenever a connection arrives. By
default, in.telnetd executes the /bin/login program, but can be made
to execute a different program via the -L switch.

in.telnetd itself has its stdin/stdout connected to the socket. It
creates a pty (pseudo-tty), and runs a program with its stdin and
stdout connected to the pty. in.telnetd handles the details of the
telnet protocol.

For a telnet BBS, you would have in.telnetd run your BBS program
instead of /bin/login, i.e.

mybbs   stream  tcp     nowait  root    /usr/sbin/in.telnetd in.telnetd -L 
/usr/local/bin/mybbs

The BBS program can then work just like any other interactive program.

Similar functionality to inetd is provided by the faucet program from
the netpipes package. This will do the same thing as inetd, but for a
single port, e.g.

        faucet <port #> -in -out in.telnetd -L /usr/local/bin/mybbs

If your project requires you to deal with the socket handling, then
you should try to avoid getting distracted with other aspects (e.g. 
something as complex as Unix terminal I/O).

-- 
Glynn Clements <[EMAIL PROTECTED]>

Reply via email to