Re: network programming

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).

Cheers,

--
Andrew
.

Relevant Pages

  • Re: Java socket programming
    ... > I have a question for you: is there a way to count the number of packets ... I know data is sent byte by byte through a stream ... Sockets are a session library, which means that sockets reside in Layer ...
    (comp.lang.java.programmer)
  • Re: Consistent performance issues at high bandwidths, UDP.
    ... all createing multiple sockets should do is use more non-paged memory ... The only difference is the number of sockets and how many packets ... and every 3.1 seconds a frame took 3.8 seconds to send. ... inconsistent frame rates caused by a periodic delay in the call ...
    (microsoft.public.win32.programmer.networks)
  • Re: Consistent performance issues at high bandwidths, UDP.
    ... The only difference is the number of sockets and how many packets I'm ... In that test each frame took 40ms to send, ... explain this massive delay, but it is at extremely regular intervals. ...
    (microsoft.public.win32.programmer.networks)
  • Re: Need a script to understand names posts
    ... the physical layer of the ISO model, augmented by providing all of the logic ... a network model that does more than just detect the fact that packets ... and brings them back onto the network as if they had never been lost. ... the packets previously lost will never ever be lost again, ...
    (microsoft.public.scripting.wsh)
  • Re: Http server implementation for Windows Media Server
    ... On that level that already extra raw data even not ... similar problem applies to me as would happen with raw sockets. ... I'm assuming you are using a raw TCP ... the packets aren't ACKed because ...
    (microsoft.public.win32.programmer.networks)