A test script to fetch over HTTP on command-line

I decided to use HTTP Get request as a good test of the /net filesystem’s first deliverable (once I complete it). I plan to get connect, sendmsg and recvmsg working in order to have this work in Linux. The script just reads and writes to files, and achieves fetching a page over HTTP on Plan 9′s shell. Even so, simple cat and echo commands sent to the netfs in shell do not work, because when we echo connect <ip>!<port> to the ctl file, and exit to terminal again for next command, the file and the connection get closed. Here’s the script, that works on Plan 9:

#!/bin/rc
server=$1
port=80
clonefile=/net/tcp/clone
netdir=()

fn showme {
while (~ `{cat $netdir/status} Established*) {
line=`{read}
if (! ~ $#line 0)
echo $line
}
exit
}

<[5] $clonefile {
netdir=`{basename -d $clonefile} ^ / ^  `{cat /fd/5}
echo connect $server!$port >$netdir/ctl || exit ‘Cannot Connect’
echo connected to tcp!$server!$port on $netdir
cat $netdir/data | tr -d ‘
‘ | showme &

while (cmd=`{read}) {
echo $cmd > $netdir/data
}
}

To use this script, run it with the server ip as an argument. While using the url will work on Plan 9, I have not implemented DNS for /net on Linux yet, so even after I complete the first deliverable, only IPs will work. After you run the command, enter the request as :
GET / HTTP/1.0
Host: <hostname>

You will see the requested page fetched and displayed on your shell. It will be best to use rc from plan9ports though.

Thank you Anant for helping in finishing the above script!

Where to hook onto the tcp stack?

I recently discussed with a diagram, exactly where I plan to hook onto the existing structure in Linux. My plan is to bypass the Socket ioctl and the Socket structure, and plug in directly to the sk structure, which is a common interface to the various transport layer protocols. I plan to write my own connection create and sendpkt functions, which work with the sk structure. Initially I had planned to plug these functions into the .connect , .sendmsg etc. of proto_ops structure, but it seems unnecessary to do that. I now think I’ll call those functions directly in my FS code, when relevant commands are written to the ctl and data files.

I was recommended to look at ksocket by a friend. While the package is looking to provide BSD-style network programming in kernel I cannot hook onto the functions they are hooking on to. ksocket is simply a wrapper on top of the socket structure, and does not help me gain insight on what’s underneath. My plan currently is to work at a much lower layer than they are doing, even though we are both in kernel-space. I just find it useless overhead to maintain a socket structure, for what I am working to achieve. Doing it my way might be much harder though!

Current issue that needs solving: If I dont have sock->sk element, because I dont use a socket to represent a connection, but use a folder /net/tcp/n , then how to I associate the sk structure with it? struct file has no sk element like struct socket does…