I am new to socket programming. I want to implement what's mentioned in the subject or you can call it a chatroom. My basic purpose is just to understand how it works. I have read many tutorials but could not find exactly what i was looking for.
I have following problems:
Q 1: I am having one computer. So I am using lo (local loop) as my interface. So whatever data I am sending, I am receiving the same in the program in which I am first sending and then receiving. The vice versa is not a problem.
Q2. I have not seen accept and connect calls in context of raw socket in any tutorial. Can I actually use these calls with raw sockets?
Related
I am currently starting to learn to program sockets with the C programming language. I was wondering in the situation of a server that receives multiple messages, let's say I want to transfer a file from the client to the server. My question in this scenario is, do I have to call multiple times the accept function before calling each time the recv function? Or can I simply accept once the connection from the client side once and call multiple times recv?
Assuming that you are using TCP connections ("socket programming" covers a wide variety of topics, but TCP is the most common) accept completes the connection via sockets between your application and a counterparty and sets up a different socket that should be used to transfer data. The actual data transfer happens on this new socket. So only call accept once per connection.
See this page for a detailed description of what accept does.
I am new to C Socket Programming. I know how to write for TCP and UDP as different programs.
But only one server should handle both the clients.
Can anyone tell me how to write a sever that handles both TCP and UDP clients?
You cannot listen to TCP and UDP clients using 1 server socket. You can however create 2 server sockets (one TCP-server and one UDP-server). Note that it would not even make sense to have 1 server for both: UDP is connectionless so the first question arises when you try to do accept on your server socket (since it is a hypothetical hybrid version, what should accept do?).
Anyway, I assume you want two servers in the same event loop (if you don't know what it is, it is enough for you to think of it as your main-function). Since C sockets are blocking by default, you cannot run two servers right out of the box.
You can use select (Google it). If you don't know what it is, I would recommend to try it in Python first. In Python it's fairly straight forward and it will give you some insight of the concept. Basically what you do is: create multiple server sockets than "switch" between those sockets, see what sockets have read events (be it new connections or messages) and then process those events.
I can recommend libuv. It is a C library that is originally built for Node.js. Prior to libuv, they used platform-dependent event loop implementations (libev). Libuv originated as an effort to create a multi-platform library for non-blocking IO (TCP, UDP, fs, etc.). However, even if you don't want to write multi-platform code, it comes with a great API to create server sockets and listen to multiple sockets in the same event loop.
I am trying to perform multithreading on a socket in C in order to develop a connector between two different software applications. I would like it to work in the following manner. One piece of software will start running as the server, it will be performing a variety of functions including listening for a socket connection on a designated port. This software will function by it self and only use data from the connected network socket when it is established and receiving reliable data. So for this piece I would like to be able to listen to a connection, and when one is made fork a process and when data is received from this socket set some variable that will be used by some other update thread to notify it that it has these extra precision information that can be considered. On the other side of this equation I want to create a program that when it boots up will attempt to connect to the port of the other application, once this connects it will then simply call a function that will send out the information in non blocking fashion. My whole goal is to create a connector that will allow the programmers of the other two pieces of code to feel as tho they aren't dealing with a socket what so ever.
I have been able to get multi threaded socket communication going but I am now trying to modify this so it will be usable as I have described and I am confused as to how to avoid multiple access to that variable that will notify the system on the server side that the data has arrived as well as create the non-blocking interaction on the client side. Any help ill be appreciated.
-TJ
The question is not so clear to me, but if you need to make different pieces of software talking easily you can consider using a framework message library like ZeroMQ www.zeromq.org
It seems like you have a double producer-consumer problem here:
Client side Server
producer -> sender thread -> receiver thread -> consumer thread
In this case, the most useful data structure to use is a blocking queue on both sides, like intel TBB's concurrent_bounded_queue.
This allows you to post tasks from one thread and have another thread pull the data when it's available in a thread-safe manner.
I am writing a simple instant messenger program in C on Linux.
Right now I have a program that binds a socket to a port on the local machine, and listens for text data being sent by another program that connected to my local machine IP and port.
Well, I can have this client send text data to my program, and have it displayed using stdout on my local machine; however, I cannot program a way to send data back to the client machine, because my program is busy listening and displaying the text sent by the client machine.
How would I go about either creating a new process (that listens and displays the text sent to it by the client machine, then takes that text and sends it to the other program's stdout, while the other program takes care of stdin being sent to the client machine) or create 2 programs that do the separate jobs (sending, receiving, and displaying), and sends the appropriate data to one another?
Sorry if that is weirdly worded, and I will clarify if need be. I looked into exec, execve, fork, etc. but am confused as to whether this is the appropriate path to look in to, or if there is a simpler way that I am missing.
Any help would be greatly appreciated, Thank you.
EDIT: In retrospect, I figured that this would be much easier accomplished with 2 separate programs. One, the IM server, and the others, the IM clients.
The IM Clients would connect to the IM server program, and send whatever text they wanted to the IM server. Then, the IM server would just record the data sent to it in a buffer/file with the names/ip's of the clients appended to the text sent to it by each client, and send that text (in format of name:text) to each client that is connected.
This would remove the need for complicated inter-process/program communication for stdin and stdout, and instead, use a simple client/server way of communicating, with the client programs displaying text sent to it from server via stdout, and using stdin to send whatever text to the server.
With this said, I am still interested in someone answering my original question: for science. Thank you all for reading, and hopefully someone will benefit from my mental brainstorming, or whatever answers come from the community.
however, i cannot program a way to send data back to the client machine, because my program is busy listening and displaying the text sent by the client machine.
The same socket that was returned from a listening-socket by accept() can be used for both sending and receiving data. So your socket is never "busy" just because you're reading from it ... you can write back on the same socket.
If you need to both read and write concurrently, then share the socket returned from accept() across two different threads. Since two different buffers are being used by the networking stack for sending and receiving on the socket, a dedicated thread for reading and another dedicated thread for writing to the socket will be thread-safe without the use of mutexes.
I would go with fork() - create a child process and now you have two different processes that can do two different things on two different sockets- one can receive and the other can send. I have no personal experience with coding a client/server like this yet, but that would be my first stab at solving your issue...
As #bdonlan mentioned in a comment, you definitely need a multiplexing call like select or preferably poll (or related syscalls like pselect, ppoll ...). These multiplexing calls are the primitive to wait on several channels at once (with pselect and ppoll able to atomically wait for both I/O events and signals). Read also the select tutorial man page. Of course, you can wait for several file descriptors, and you can wait for both reading & writing abilities (even on the same socket, if needed), in the same select or poll syscall.
All event-based loops and frameworks are using these multiplexing calls (like poll or select). You could also use libevent, or even (particularly when coding a graphical user interface application) some GUI toolkit like Gtk or Qt, which are all based around a central event loop.
I don't think that having a multi-process or multi-threaded application is useful in your case. You just need some event loop.
You might also ask to get a SIGIO signal when data arrives on your socket using fcntl with F_SETOWN, but this is not very useful for you. Then you often want to have your socket non-blocking.
I want to send the two different packets in different port numbers parallely using UDP.
Can I achive this using single socket() or should I create another socket??
Can anbody give me some idea on this.
Thanks in advance
You can use a single socket, you will be using the system calls sendto(2) and recvfrom(2) to send and receive data over the datagram sockets.
Take a look at https://beej.us/guide/bgnet/html/multi/syscalls.html for more information (the entire guide is definitely worth the read).
Beej's guide on socket programming