Post #225,425
9/19/05 7:02:40 AM
|
Wel, it's beautiful code
But won't it turn a course on TCP/IP into a course on Python networking libraries? The question is, what's the goal of the course? Is it to be able to do things on the net, or to understand how the net realy works?
------
179. I will not outsource core functions.
--
[link|http://omega.med.yale.edu/~pcy5/misc/overlord2.htm|.]
|
Post #225,430
9/19/05 7:38:22 AM
|
Use the socket libraries then.
Readable code is more about structure and obviousness than libraries.
Regards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #225,442
9/19/05 10:33:04 AM
|
It's introduction to networking
but I have programmers in the class.
The idea was to give them just enough to shoot a few bytes across a LAN.
Give them a little Marconi Moment, as it were.
Another possibility is to show them some network hacking with nmap, Metasploit et al.
Tom Sinclair
The place looked as though it had been visited by Gengiz Cohen [footnote:
hence the term "wholesale destruction"].
-- (Terry Pratchett, Lords and Ladies)
|
Post #225,444
9/19/05 10:52:57 AM
|
I'd go with socket basics.
It's not that difficult conceptually, and will make How It All Works much clearer than any other thing you can do. After all, once you get the connection made and can pass text back and forth, creating a service is just all about how it's processed at each end.
To my mind, I'd start with the socket basics, keep it quite basic, and point them at further info if they wish to follow up on their own. After seeing how sockets work, showing them the kinds of things you can do with nmap etc will be much much clearer to them. Start down near the root, and move the course further up the tree as it progresses.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #225,451
9/19/05 11:23:15 AM
|
Re: I'd go with socket basics.
Server: #!/usr/bin/python\n\nimport sys, socket\n\nif (len(sys.argv) < 2):\n sys.exit('Must supply port!\\n')\n\nport = sys.argv[1]\nhost = socket.gethostbyname(socket.gethostname())\n\nprint '%s:%s Listening:\\n' % (host, port)\n\nsock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\ntry:\n sock.bind((host, int(port)))\n sock.listen(1)\n\n conn, addr = sock.accept()\n print 'Connection from: ' + str(addr)\n\n str = conn.recv(1024)\n print 'Echoing "%s"' % (str)\n conn.send(str)\n\n conn.close()\n\nexcept socket.error, (errno, errstr):\n conn.close()\n sys.exit("Error: %s!" % (errstr))Client: #!/usr/bin/python\n\nimport sys, socket\n\nif (len(sys.argv) < 4):\n sys.exit('Must supply host, port, and text string to send!\\n')\n\n(host, port, string) = sys.argv[1:]\n\nprint '%s:%s Sending: %s\\n' % (host, port, string)\n\nsock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)\ntry:\n sock.connect((host, int(port)))\n sock.sendall('%s\\n' % (string))\n recv = ''\n while 1:\n str = sock.recv(1024)\n if not str: break\n recv += str\n\nexcept socket.error, (errno, errstr):\n sock.close()\n sys.exit("Error: %s!" % (errstr))\n\nprint "Received:\\n" + recvRegards,
-scott anderson
"Welcome to Rivendell, Mr. Anderson..."
|
Post #225,458
9/19/05 12:50:17 PM
|
Didn't say it would take very long
:)
Of course, for the students that DON'T know programming, learning that will take quite a bit longer; OTOH, once they DO grok it, they will be much better positioned to correctly grok computers in general.
There are a LOT of users that have very, ummm, odd intellectual models of what's actually going on in there.
Cue Tom Waits as appropriate.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #225,461
9/19/05 1:02:31 PM
|
Programming Languages will influence the model
So one must be careful to choose a PL that has the proper level of abstraction for the lesson to be taught and the model to be molded. If you want them to understand it in terms of bits and bytes and machine instructions, C and it's ilk is the way to go. If you want them to understand it as a set of libraries that can be slowly dissected, then Python and similar languages can be the way to go.
Either way, both are really just models for the more abstract thought of network transport.
|
Post #225,468
9/19/05 1:29:34 PM
|
Indeed
and I think a higher level view than C is the one for this. I might get a kick out of bit hacking from time to time, but I'm funny and strange. The key concept is two apps, one with a listen socket and one connecting to it, exchanging data through a series of read and write operations to their end of the socket. Once they grok that, then things like the output (in OS/2) of iptrace && ipformat get a lot easier to figure out. --\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #225,481
9/19/05 3:03:14 PM
|
Definitely want high level languages
Keep this at the upper levels of the TCP/IP stack.
Tom Sinclair
Crowley was in Hell's bad books. Not that Hell has any other kind.
-- (Terry Pratchett & Neil Gaiman, Good Omens)
|
Post #225,538
9/19/05 8:22:01 PM
|
Yep.
------
179. I will not outsource core functions.
--
[link|http://omega.med.yale.edu/~pcy5/misc/overlord2.htm|.]
|
