|
|||||||
|
|
|
|||||
|
|
|||||||
The TCP/IP part of the kernel is called
into action when an arriving IP fragment causes an interrupt at the device
driver.Using the kernel data,it is matched up with any other fragments
that might have arrived.When it is complete,the IP module in Domainatrix
takes over,checking for ICMP messages,or TCP/UDP.For the latter,the complete
packet is now matched to the process which has a socket open for it,and
handed over to that app in its "Read" segment.Domainatrix's TCP/IP already
piggybacks ACKs by keeping a timer-based entry in its data tables to keep
track of what packets have arrived,and are expecting ACKs.
Writing works just about the same way in
reverse.The data to be written is copied into a buffer area and memory
is extended to make room for the headers to be added to it.Though at one
point I was contemplating using scatter/gather,ie. to build up and send
the headers first before sending the data,I decided to drop that idea,because
there might be an unacceptable delay between the time those two occur.
I propose for the future to introduce something
I call LiveSocket(),to help stream live multimedia sources,ie. audio or
video over the Internet,while keeping the copying in the data buffers to
a minimum - the basic idea is that a programmer will be able to specify
when creating a socket whether it is Live or not,and associate it with
a particular device,which would result in every subsequent read() being
done done from that device resulting in that data being sent out to the
network,without *anything further* having to be done by the programmer!!.It
might possibly be have to be put through a pipe first eg. for encoding
compressed video from a video source [1],which would also be a parameter
to the socket() call.The above would be slightly tricky,because of course,a
socket such as the above would be created when a *remote* request comes
through,not when the programmer decides to create it,and its status would
have to be changed to Live at a later stage,however it is a simple matter
to specify to the OS that all sockets created with a particular (Local
IP,Local Port) duo should be Live.
Though the socket interface has been in
existence for a pretty long time, it may not be the best abstraction possible.Since
I wrote Domainatrix to primarily be a hacker's OS, it's my intention to
provide a programmer with total control over the packets emanating from
the computer.As such this interface,while provided now,may be changed completely
in the future.For example,the connect() system call at the moment completes
the 3-way handshake for you,you may not want this to be the case (not that
I advocate SYN-flooding someone or something,however if you WANT to,you
should be able to do it).
TODO:
Heh heh,what's left in a 100% asm TCP/IP
stack? Well,let's see now..... No PSH handling yet.This is the first thing
needed to PSH it towards RFC 1122 compliance (no pun intended),and is going
to take quite a bit of coding....any takers?
ICMP handling: not a thing done yet.Also,have
to get that v6 stuff started... not that it's going to be *very* different,but
still,hasn't been done yet.......
REFERENCE
NAIVE : Network Aware Internet Video Encoding - Hector Briceno (MIT),Steven Gortler (Harvard University),Leonard McMillan (MIT).