Re: network programming
- From: Andrew Reilly <andrew-newspost@xxxxxxxxxxxxxxxxxxxxx>
- Date: 12 Dec 2007 05:31:09 GMT
On Wed, 12 Dec 2007 05:52:40 +0100, Andreas Davour wrote:
Let's just say 'ok' is a few steps below 'good'. I did take a course
once about TCP/IP and read a few books. After that I knew a lot about
how an IP header is formed and in what OSI layer they fit. I always
wondered how they were justed for anything except ftp and telnet which
is what everyone used as examples. I still know about those bits in a
UDP datagram, I have an 'ok' grasp on that.
TCP/IP doesn't exactly fit the OSI layer model in many respects, and
you'll find plenty of people who will argue that that's because TCP/IP
works in practice, and OSI doesn't. (I'm not one of those people: OSI
was essentially gone before I got to do much network programming, so I
never got a good look at it being used in practice.)
So sockets actually bypass the transport layer?
Sockets abstract part of the transport layer. Vis you can have several
different kinds of sockets (IPv4, IPv6, Unix Domain, etc) that let you
communicate using different transport protocols.
It almost sounds like
they were implemented by someone who either didn't know about or didn't
like the rest of the stack, or are there any good reason not to utilize
TCP for the functionality that sockets provide?
Yes. There are applications (particularly real-time) where it's better
to lose a packet than to delay delivery of subsequent packets while you
ask for a re-transmit. Just by way of example. There are lots of other
protocols that use/prefer UDP and the like. These still use sockets
(unless you're using STREAMS (the shouted, AT&T/Solaris variety)).
Depends on what you want to do. Some libraries don't support "raw"
packets so if you need them you may have to use FFI to access the OS
API. However, only applications that need to monitor or control
networks at the link layer need to use raw packets. Virtually all
other applications can make due with IP datagrams or TCP streams.
That would be the reason to have the underlaying level written in
something more sensible than C, to not be dependant on FFI.
But, I guess I will not use raw packets soon anyway.
Inventing new protocols on the packet/datagram level you would actually
get by with "raw" packets?
There's also the issue of multiplexing/demultiplexing packets to
applications, in a multi-tasking operating system. Below the socket
layer you really want to be in the operating system, so that you can pass
packets to the applications that are waiting for them. (You might want
to have a look at how the Minix3 network stack works: it doesn't use the
Berkeley Sockets model: network connections appear in the filesystem name
space, where regular file operations work on them.)
You are perfectly correct to suggest that actually implement a stack
myself is way beyond my present capabilities! My problem is I want to
know how things work, all the way down, and sometimes don't know when to
stop. You know how they say that most programmers most often start
projects to "scratch an itch"? My itch is the operating system!
There have been Lisp operating systems before (from the silicon up), and
there are projects to build new ones. These will probably/necessarily
have network stacks implemented in Lisp. There's no reason why they
couldn't be (unless your Lisp is running on top of another OS).
- Re: network programming
- From: Andreas Davour
- Re: network programming
- Prev by Date: Re: network programming
- Next by Date: Re: a challenge for lispers
- Previous by thread: Re: network programming
- Next by thread: Re: network programming