Re: [clisp-list] Doing everything with bytes => rawsock

[<don...@is...>]

Sam Steingold writes:
 > OS support is on a feature-by-feature basis.
Which features are supported by which os's and how does one in general
find out?
 > tests serve two major goals:
 > 2. Demoing the functionality:
Of course some of this could be done in the doc.

 > > If you do have root access and a typical network connection, you could
 > > use raw sockets to implement things like ping or traceroute, or
 > > tcpdump but testing these things relies on the behavior of other
 > > machines.
 > ping does not require root.
Although ping does not require root, an implementation of ping using
rawsock WOULD require root, because you would be opening a raw socket.

 > if you can write a bare-bones ping/tcpdump/traceroute, I would love
 > to add them to rawsock/demos/, similar to new-clx/demos/.
 > e.g., can you make it possible to do
 > $ clisp -i rawsock/demos/ping -x '(ping:ping "www.gnu.org")'
Yes, it would be pretty straight forward but
- would require root
- would require a lot of inputs describing things like what network
  interface to use, what IP address, etc.  Reasonable defaults for
  these things can generally be determined by various system calls
  or shell commands, but those are also system dependent, even more
  so than raw sockets themselves.
- the first step would be finding the ip address for www.gnu.org
  (unless you're willing to enter the ip address instead)
  This is yet another thing that could be done with raw sockets
  (dns client), but again requires a lot of system dependent things,
  such as what dns server to use -- or where to find out

I suppose the most straight forward and portable way to find the
ip address of www.gnu.org would be to create a tcp socket to it and
read the address from that -- but of course a real ping would be
pretty useless if it required first creating a tcp connection to the
target.

 > okay, so the code will not be automatically run.
 > it is still very valuable, both as a test (ran by hand) and as a demo.

Above only begins to hint at how low level this stuff is.  This is a
problem for demos because there are too many details for anyone to
want to control, but it's not clear which ones the user (demo viewer)
will want to control, and each one leads to its own issue of how to
even find out which options are available.  I could write something
that would work out of MY box, but when it fails on your box you'll
have to understand a lot in order to figure out why. 

 > > In fact, ideally the tests would make use of a raw socket
 > > interface on that other machine.
 > "ssh host clisp" is your friend.
So you're now suggesting that the test script require a parameter
of a partner host directly connected to this one to which you can 
ssh without a password and run clisp on it in a place where the
necessary code will already be installed?
This does not sound like a reasonable requirement for a test.
It might be for a demo, but not a demo that a normal person can
be expected to run on his own.