I am a beginner to networking and I have a few questions regarding networking.
1)How can a process execute code that is sent from a different computer on the network. Generally a process's code segment cannot be changed once its loaded to ensure protection. (Also I can execute some arbitrary code to corrupt the process's memory)
2)Also can a process hear to multiple ports ? And multiple processes can hear to a same port ? For example two https associated with port 80. How to distinguish between the processes and how to ensure protection ?
3)Also I would like to know how listen is implemented in sockets. Are they implemented as software interrupts ?
Any good book recommendations are very much appreciated.
Thanks & Regards,
Mousey.
Q: How can a process execute code sent from another machine?
A: Generally, this is a bad idea as the security concerns are difficult to fully explore. However, this can be done by saving the network-delivered code to a separate executable and then launching this new program. This can also be done on most systems by just treating the raw bytes received as code; load the bytes into the heap (not the stack!), cast the address to a function pointer, and call it. Again though, this is almost certainly a bad idea.
Q: Can a process listen on multiple ports simultaneously?
A: Yes. By the way, HTTPS is port 443. HTTP is port 80.
Q: Can multiple processes listen on the same port (with the same protocol, on the same address)?
A: No. Other processes might be able to eavesdrop and also receive the packets, but they're not directly bound to the port. In general, only one process can be bound to a given protocol/port/address 3-tuple.
Q: How is blocking while listening on a socket implemented?
A: By the operating system, in its own fashion. Generally a thread is moved into the "blocking" state when it calls accept, read, or poll/select on a non-ready socket, and will not receive CPU time until some data have arrived.
1)How can a process execute code that is sent from a different computer on the network. Generally a process's code segment cannot be changed once its loaded to ensure protection.
This has nothing to do with networking. Once you receive the data through a socket, it's in your local memory. What you do after that is OS-specific. For example, on Windows, you can use VirtualProtect to mark pages as executable.
2)Also can a process hear to multiple ports ?
Sure, just create a different socket for each port you want to listen to. Of course, to use them simultaneously, you either need to use non-blocking sockets or run each socket in a separate thread.
3)Also I would like to know how listen is implemented in sockets. Are they implemented as software interrupts ?
This is entirely OS-specific. listen just sets up the socket so that it can accept connections. Any connection requests that arrive after this (this probably happens somewhere in the TCP/IP driver) are put in a queue by the OS. When you later call accept, the OS pulls out the first pending connection from this queue and returns a socket to that.
Related
I am writing a server application that simply connects a local serial port to multiple network connected clients. I am using linux and C for the server application because the equipment for the program is a router with limited memory.
I have everything setup for multiple clients to connect and send data to the serial port using a fork() process for each connection.
My problem lies in getting data incoming on the serial port out to the multiple (varing number) client connections. my problem lies in designing a way for each active socket to get all of the incoming data, and to only get it once. Any help?
Sounds like you need a data queue (buffer) for each connected client. Each time data comes in on the port, you post it to the back of each client's queue. The clients then read the data from the front of their respective queues. Since all the clients will probably read at different rates/times, this will ensure all of them get a copy of the data only once, and you won't get hung up waiting for any one client while more data comes in. Of course, you'll need to allocate a certain amount of memory for each connected client's queue (I'm not sure how many clients you're expecting, and you did say your available memory is limited), and you need to consider what to do if a queue gets full before the client reads all of it.
Presumably you keep a list or some other reference of/to connected clients, why not just loop over that for each bit of information and send it to all of them?
A thread per socket design might not be the best way to solve this. An event driven asynchronous approach should be a much better fit. However, if you must do it with threads, and given that serial ports are slow anyway, building a pipe between the thread listening to the serial port and all the threads talking to the network clients is the most practical. You could do fancy things with rwlocks to move the data, but you'll still need a way for the network threads to wait on both the socket and the data from the serial port, so you need to use file descriptors for both and something like poll.
But seriously, this would likely be much easier and would perform better without the threads. Think of it as a main loop which waits on poll which is watching the network and the serial port, determines which event occurred, and distributes data accordingly. It should be easier all around once you get the idea.
I've not a clear idea about when I have to use the bind() function.
I guess it should be used whenever I need to receive data (i.e. recv() or recvfrom() functions) whether I'm using TCP or UDP, but somebody told me this is not the case.
Can anyone clarify a bit?
EDIT I've read the answers but actually I'm not so clear. Let's take an example where I have an UDP client which sends the data to the server and then has to get a response. I have to use bind here, right?
This answer is a little bit long-winded, but I think it will help.
When we do computer networking, we're really just doing inter-process communication. Lets say on your own computer you had two programs that wanted to talk to each other. You might use pipe to send the data from one program to another. When you say ls | grep pdf you are taking the output of ls and feeding it into grep. In this way, you have unidirectional communication between the two separate programs ls and grep.
When you do this, someone needs to keep track of the Process ID (PID) of each process. That PID is a unique identifier for each process and it helps us track who the "source" and "destination" processes are for the data we want to transfer.
So now lets say you have data from a webserver than you want to transfer to a browser. Well, this is the same scenario as above - interprocess communication between two programs, the "server" and "browser".
Except this time those two programs are on different computers. The mechanism for interprocess communication across two computers are called "sockets".
So great. You take some data, lob it over the wire, and the other computer receives it. Except that computer doesn't know what to do with that data. Remember we said we need a PID to know which processes are communicating? The same is true in networking. When your computer receives HTML data, how does it know to send it to "firefox" rather than "pidgin"?
Well when you transmit network data, you specify that it goes on a specific "port". Port 80 is usually used for web, port 25 for telnet, port 443 for HTTPS, etc.
And that "port" is bound to a specific process ID on the machine. This is why we have ports. This is why we use bind(). In order to tell the sender which process should receive our data.
This should explain the answers people have posted. If you are a sender, you don't care what the outgoing port is, so you usually don't use bind() to specify that port. If you are a receiver, well, everyone else has to know where to look for you. So you bind() your program to port 80 and then tell everyone to make sure to transmit data there.
To answer your hw question, yes, your probably want to use bind() for your server. But the clients don't need to use bind() - they just need to make sure they transmit data to whatever port you've chosen.
After reading your updated question. I would suggest not to use bind() function while making client calls. The function is used, while writing your own server, to bind the socket (created after making a call to socket()) to a physical address.
For further help look at this tutorial
bind() is useful when you are writing a server which awaits data from clients by "listening" to a known port. With bind() you are able to set the port on which you will listen() with the same socket.
If you are writing the client, it is not needed for you to call bind() -- you can simply call recv() to obtain the data sent from the server. Your local port will be set to an "ephemeral" value when the TCP connection is established.
You use bind whenever you want to bind to a local address. You mostly use this for opening a listening socket on a specific address/port, but it can also be used to fix the address/port of an outgoing TCP connection.
you need to call bind() only in your server. It's needed especially for binding a #port to your socket.
Appreciate if anyone can help me to get a better solution...
In my application, there is a TCP client(C) and other TCP server(S) on linux machine.
On production envoronment, on high load this server sometimes stop receiving request from Client and hence creating bottlenecks for client as client side is a blocking socket.To recreate the problem locally .. i put a load and take the server on GDB and this way the problem is recreated.
Can anyone suggest some other mechanism to block the socket wihout disturbing the process ?
What exactly would you like to hear? If the server is busy, that is, other processes are being serviced because they too do get a share of the timeslices by the scheduler, there is not much you can do except raising your program's priority/timeslice length, or lowering theirs.
Note that TCP implementations generally use a socket buffer so that some transfers can continue to happen while a process is currently busy dealing with data, or while waiting for the next timeslice.
Do you have some code to show?
Can anyone suggest some other mechanism to block the socket wihout
disturbing the process ?
Do the connection in a separate thread so that you do not block the whole process
I didn't really get the point, but I guess you have implement a blocked tcp server.
If this is true, then there may be some methods to solve it
Use multithreading or event-driven architecture to improve I/O efficiency.
Extract I/O methods code from the others
Multiprocessing may be required to avoid system limits, such as the count of open files.
I wrote a program that creates a TCP and UDP socket in C and starts both servers up. The goal of the application is to monitor requests over the TCP socket as to what UDP packets to send it (i.e. monitor for something like "0x01 0x02" and if I see it, then have the UDP server parse the payload, and forward it over to the TCP server for processing). The problem is, the UDP server will be busy keeping another device up, literally sending thousands of packets back and forth with this device. So what is the best way to continuously monitor requests from the TCP server, but send it certain payloads from the UDP server when requested since the UDP server will be busy?
I looked into pthreads with semaphores and/or mutex (not sure all the socket operations are thread safe, though, and if this is the right way to approach it) as well as fork / pipe. Forking the UDP server off as a child process seems easy enough, but I don't see exactly how I would be passing the kind of data I need among both servers (need request data from TCP and payload data from the UDP).
Firstly, would it make sense to put these two servers into one program? If so, you won't have to communicate between processes, and the whole logic becomes substantially easier. You will have to think about doing asynchronous input and output, and the select() function is designed for just this. There will be many explanations around on how to do this, and a quick look finds this page.
However, if you must have two separate processes, then you will need to choose a mechanism for inter-process communication, of which there are several, and your choice will be affected by your operating system. A pipe, if available, might be suitable, as might a Unix named pipe. Or you could look into third-party message passing frameworks, or just use shared memory and/or semaphores (but be very careful!).
What you should look at is libevent, anything else you are reinventing the wheel writing this low level code yourself. Here is a Tutorial, Google, Krugle
Also you should use some predefined protocol between the servers. There are lots to choose from. Ranging from the extremely simple XDR to Protocol Buffers.
You could use pipes on Unix. See http://tldp.org/LDP/lpg/node11.html
Well, you certainly picked an interesting introduction to C!
You might try shared memory. What OS?
If i use UDP sockets for interprocess communication, can i expect that all send data is received by the other process in the same order?
I know this is not true for UDP in general.
No. I have been bitten by this before. You may wonder how it can possibly fail, but you'll run into issues of buffers of pending packets filling up, and consequently packets will be dropped. How the network subsystem drops packets is implementation-dependent and not specified anywhere.
In short, no. You shouldn't be making any assumptions about the order of data received on a UDP socket, even over localhost. It might work, it might not, and it's not guaranteed to.
No, there is no such guarantee, even with local sockets. If you want an IPC mechanism that guraantees in-order delivery you might look into using full-duplex pipes with popen(). This opens a pipe to the child process that either can read or write arbitrarily. It will guarantee in-order delivery and can be used with synchronous or asynchronous I/O (select() or poll()), depending on how you want to build the application.
On unix there are other options such as unix domain sockets or System V message queues (some of which may be faster) but reading/writing from a pipe is dead simple and works. As a bonus it's easy to test your server process because it is just reading and writing from Stdio.
On windows you could look into Named Pipes, which work somewhat differently from their unix namesake but are used for precisely this sort of interprocess communication.
Loopback UDP is incredibly unreliable on many platforms, you can easily see 50%+ data loss. Various excuses have been given to the effect that there are far better transport mechanisms to use.
There are many middleware stacks available these days to make IPC easier to use and cross platform. Have a look at something like ZeroMQ or 29 West's LBM which use the same API for intra-process, inter-process (IPC), and network communications.
The socket interface will probably not flow control the originator of the data, so you will probably see reliable transmission if you have higher level flow control but there is always the possibility that a memory crunch could still cause a dropped datagram.
Without flow control limiting kernel memory allocation for datagrams I imagine it will be just as unreliable as network UDP.