This was a cool system call because all socket operations use the same system call but modulate what the call does based on what is in the ebx register. This feels like sockets were bolted on after the fact or there was some reason to move logic inside the system call itself.
The socket call also expects arguments on the stack and you need to pass in the esp to the call. This is similar to what I did for the shell assembly program that I wrote.
This lesson also uses the xor method to 0 out the needed registers.
Socket creation returns a file descriptor but I know c uses the send and recv functions. I wonder why we don't just use the read and writes.
The binding of an ip address and a port to a socket is much more involved. It requires pushing and manipulating the stack to pass arguments through into the socket system call. Very cool call.
A simpler system call is the listen call. It looks like because all the socket functions are inside the socket system call that the stack is much more involved than the previous system calls I saw.
This was simple lesson in the context of how sockets work.
A good lesson and this goes over the fork system call as well. When we accept on a socket, we can then read from it or we can fork it off. If it is the parent process, it will fork but when it is the child process it will call the read subroutine. It looks like a client will connect to the port, immediately trigger the accept and get a new socket that the client will then send the real request to.
The cool thing here is that I implemented this method in basic but because there is no forking I had to have the child process be the listening part of the process whereas when you have fork available the child can be spun off. The effect in my webserver is that it goes down momentarily before it can spin back up. There may be a better way to do it now that I know how it works a bit better here.
An interesting thing to note here is that the sys_read is used to read from the socket. C however uses the recv, I learned that sockets can use read and write but send and recv and specialized versions for sockets.
A very simple lesson that uses what was shown in previous lessons. The cool thing is because everything is a file the read and writes are very familiar. The socket interface itself is rough but the actual communication over it seems straightforward.
A simple lesson to close a socket. This is the same as in the file handling section.
This lesson goes over the connect function in the socket system call.
With that I have gone through all the lessons on assembly and I think I have decent handle on assembly programming under linux. I realize now that it is very much specific to Linux and that I assume other operating systems will have a different form of assembly. However I think this was a good learning experience in general.
The other big thing is that I really like the structure of these lessons and how they were building on top of each other. I think it could have been organized a bit better but it is quite good. The general pattern seems to have been to first print something to the screen, then user input, then write to files and finally write to sockets. These things are probably the most common parts of programming and seeing them in assembly is quite valuable.