How to monitor my own private fd using D-bus? [closed] - c

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 6 years ago.
Improve this question
I have some doubt when taking D-bus IPC into my client program.
In my opinion, D-bus has its own way to manage the low-level socket.
The socket fd is packed into a 'DBusConnection', and then be used to communicate with daemon, write/read/dispatch/loop. That's ok.
But if the client needs to directly monitor/select another socket, such as monitor a tcp port, using its own way sometimes.
Is D-bus fit for this situation ? How could I select the two sockets at the time when using with D-bus ?
Is D-bus designed to communicate with other local processes only via 'DBusConnection' connecting with daemon ?
I just start to use D-bus, and really confused.
Any help will be appreciated ~
Sorry I did not present it clearly.
I'll take with an example to detail it.
Some guys familiar with D-bus may have looked up the source code of 'dbus-monitor', one tool attached to D-bus.
'dbus-monitor' uses 'dbus_bus_get' to create a connection with daemon,
and then call 'dbus_connection_get_object_path_data' to tell dameon which objects it support, and so forth( sth not cared here ),
finally, '_dbus_loop_run' for main loop.
With curiosity, I have done some diving work about the implementations of these D-bus APIs. ( It's not enough obviously. )
From my point of view, same with the usual IPC logic, the essential work of these steps looks like (May be it's not quite sure.) : open a local socket, connect to the server(daemon), read/write/select (the server uses epoll) socket fd.
Ok, thanks for your patience. fine~
In order to communicate with daemon, D-bus creates a socket and uses its own way(API) to manipulate the socket. ( the socket fd is encapsulated into
D-bus's connection structure -- 'DBusConnection', we can NOT directly operate it. )
Now my question is if I need D-bus to create a 'DBusConnection' (encapsulate a local socket fd) to talk to the daemon, like 'dbus-monitor'.
And at the same time, my client application also needs to create another socket fd to monitor a tcp port.
I wonder whether there is a way to simultaneously 'select' these two kind of socket fd? ( one encapsulated in D-bus's connection structure
which can NOT be select explicitly, another is a general socket fd. )

Related

Make Applications discover each other via UDP [closed]

Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
This question does not appear to be about programming within the scope defined in the help center.
Closed 3 years ago.
Improve this question
I want to make a application in C on Linux where there are multiple processes running on one computer, which come from the same binary. It is not exactly defined how many of these processes there will be (2-20). I want them to find all the other running instances of the binary when they start up. The processes should communicate over UDP with Linux Sockets and when one application sends a packet every process should receive it.
At the moment i have set up some basic udp message sending between two clients with fixed predefined ports. The goal ist to have them start up and get some port assigned from the os. The applications then should find other instances of the same binary and communicate with them. How can implement this sort of searching ? At first i tried to make them all listen to some fixed port via SO_REUSEADDR, but then just the last process to start up will receive all traffic. Then i looked into Multi and Broadcasting, but i think i need different ips for that to work.
Thanks in advance
Each instance of your application should create a socket that is bound to the same port. You'll need to set the SO_REUSEADDR on the socket before binding to allow this to happen.
As you've already found, when you have multiple UDP sockets bound to the same port and a unicast packet arrives only one of those sockets will receive the packet. To get around that you'll have to use multicast. If the sockets are all listening on a multicast address and a multicast packet it sent, all sockets will receive the packet. This also has the advantage of working whether or not the processes are on the same host.
After you set SO_REUSEADDR and bind the socket, you'll want to join a multicast group by setting the IP_ADD_MEMBERSHIP option. You can use any valid multicast address for this in the 225.0.0.0 - 239.255.255.255 range (avoid 232.x.x.x as that is for source specific multicast) and all instances of the app should join the same group.
You should also set the IP_MULTICAST_IF option to set the network interface for outgoing multicast packets, and if you want the app to receive multicast messages that it sent itself, you'll also want to set IP_MULTICAST_LOOP.

What Linux Port is always writing [closed]

Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I am experimenting reading (and eventually writing) serial ports in C. I want to be able to connect to a port on debian and read in some data but I need a port that is writing (speaking). I am new to linux programming.
What port, that will definitely be present and talking in debian, can I connect to to read some data in?
Can you also suggest a port I can eventually use to write to aswell?
I've tried connecting to /dev/ttyUSB1 that this example uses but that port doesn't exist.
I would suggest either open /dev/random (or /dev/urandom) as Paul suggests or create your own socket and read/write to that. Don't just pick an arbitrary socket and hope it has information that no other process needed.
If this is your first time working with sockets I would also suggest that you try playing around with things in a language like python simply because you don't need to recompile to see where you went wrong and the warnings are often more readable (take a look at https://docs.python.org/2/howto/sockets.html)
As a side note: If you have access to an arduino you might like to try connecting to that socket (usually something like ser = serial.Serial('/dev/ttyACM0', 9600) in python).

Client/Server Program in C

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.

Chat server and client implementation? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I've been dying to implement a chat server in C and Winsock for a long time now, but I haven't taken the time. Partly, because I'm still unsure of some of the conceptual ideas about building a server on Windows OS'es for something like chat.
Here are some of the issues I've been thinking about :
How will user x connect to my server over a generic LAN
without me relying on them to type in a network address( e.g. address
could be invalid, redirected to a different server, etc. )
If I use broadcasting to solve the above problem, will that be reliable enough for chat?
Will that potentially DDos a LAN since the packets will be be forcibly handled on every machine and may take a lot of bandwidth if enough people join?
What is the difference between multicasting and broadcasting? Is multicasting truly superior?
Etc.
Per request, my definition of reliability would be that I can get most of the data consistently in sent packets. In other words, I don't mind a few dropped packets, but I do mind if the data gets messed up quite a lot along the way.
Currently, I have a lot more questions than answers, but the main point I'm getting at is this :
What is the safest and most reliable way of implementing a chat over a LAN in C and Winsock?
How will user x connect to my server over a generic LAN without me relying
on them to type in a network address( e.g. address could be
invalid, redirected to a different server, etc. )
Use a closed list of known servers, or use some broadcast based autodiscovery system.
If I use broadcasting to solve the above problem, will that be reliable
enough for chat?
Define your requirements for reliability.
Will that potentially DDos a LAN since the packets will be be forcibly
handled on every machine and may take a lot of bandwidth if enough
people join?
It's a chat... the amount of generated packets will be comparatively short and small.
What is the difference between multicasting and broadcasting? Is
multicasting truly superior?
Search the web. There are lots of resources and information about multicasting, most precisely, IP multicasting. In short:
Broadcast delivers to all hosts on a broadcast domain. Multicast delivers to all hosts that have explicity joined a multicast group, which may not be in the same broadcast domain (see last point).
Broadcast forces a switch to forward broadcast packets to all its interfaces. Intelligent switches can benefit from peeking at IGMP packets to know which interfaces multicast packets have to be forwarded to.
Broadcast cannot treepass a broadcast domain. Multicast packets can traverse a router, if it's configured to route multicast (search for M-bone)

Opening Multiple TCP Connections From A Client To A Server Using Random Source Port In C

I am writing a C program where for every new request to be processed by server, I need to open a new TCP connection? That is every request from client needs to be handled by a separate TCP connection to a server listening on a particular port.
Can someone help me in code pointers?
How to maintain array of this socket identifiers (multiple sockets that needs to be opened)
How will I be able to read (Need to scroll through all open sockets and see if something interesting is to be read upon that socket)
Any code snippet will be highly useful?
You can use the select() function (assuming you are working with <sys/socket.h>), "gives you the power to monitor several sockets at the same time. It'll tell you which ones are ready for reading, which are ready for writing, and which sockets have raised exceptions" from http://beej.us/guide/bgnet/ (here you can download a pretty good book on network programming basics).
For a server example using select check http://beej.us/guide/bgnet/examples/selectserver.c
Hope it helps
If you need to save state with the socket, put it in a struct together with the data you need, and link the structures together as a list. For checking which sockets are ready see Maluchi's answer.

Resources