Is it possible to run the C socket library in non-blocking mode, and trigger a function on receiving any data? The function will then evaluate the received data and decide the flow of control in the program.
It would be very helpful if you could mention some references.
Yes, using libevent library that is possible.
First create an event base
struct event_base *ev_base = event_base_new();
Create and add that event for anything received on the socket
struct event *read_ev = event_new(ev_base, socket_fd, EV_READ|EV_PERSIST, callback_function_ptr, callback_function_arg);
event_add(read_ev, NULL);
At the end of the function dispatch events
event_base_dispatch(ev_base);
Related
Are the event_base_loop()(publisher thread) and event_base_dispatch()(subscriber thread) functions thread safe? Recently I checked my application for any synchronization errors using valgrind's helgrind tool. In the report it's mentioned that there exists a race condition between event_base_loop() and event_base_dispatch() even though both these functions are called with different struct event_base variables (struct event_base base_pub(publisher thread) and struct event_base base_sub (subscriber thread)). Below is the sample code
Publisher Thread
struct event_base base_pub = event_base_new();
while (true) {
... // publish data
event_base_loop(base_pub, EVLOOP_NONBLOCK);
sleep(1);
...
}
Subscriber Thread
struct event_base base_sub = event_base_new();
while (true) {
... // register subscriber callback function
event_base_dispatch(base_sub);
...
}
They are thread-safe, if you enable locking/condition variables through:
evthread_use_pthreads();
You also need to link with libevent_pthreads. Note that:
Before you call any other Libevent functions, you need to set up the
library. If you're going to use Libevent from multiple threads in a
multithreaded application, you need to initialize thread support –
typically by using evthread_use_pthreads() or
evthread_use_windows_threads().
Currently, only one thread can be dispatching a given event_base at a
time. If you want to run events in multiple threads at once, you can
either have a single event_base whose events add work to a work queue,
or you can create multiple event_base objects.
I am doing some work on worm-attack detection in RPL. In RPL, the communication between the clients might be multiple hops, with the packets going through many nodes.
However, only the receiver gets a tcpip_event on reception of the packet. The nodes that the route passes through do not get this event. Is there any way to detect the packet on the intermediate nodes?
You cannot get a notification or callback when a packet is forwarded. However, you can get a callback when a packet is received or sent by the lower layers.
In Contiki, use the function rime_sniffer_add for that. Check apps/powertrace/powertrace.c for an example.
In Contiki-NG the function has been renamed to netstack_sniffer_add.
Usage example:
Declare the sniffer like this, in the global scope:
RIME_SNIFFER(packet_sniffer, input_packet, output_packet);
Then add the sniffer from your code, once, at the start of the application execution:
rime_sniffer_add(&packet_sniffer);
The functions input_packet and output_packets are callbacks defined by you and can be used to examine the packets; for example, like this:
static void
input_packet(void)
{
int rssi = (int)packetbuf_attr(PACKETBUF_ATTR_RSSI);
printf("received a packet with RSSI=%d\n", rssi);
}
I'm using this simple echo-server as an example.
It creates a listening connection, receives a packet, sends it back and then closes the connection.
In the initialization function, accept callback is registered in lwip like this:
void
echo_init(void)
{
echo_pcb = tcp_new();
...
echo_pcb = tcp_listen(echo_pcb);
tcp_accept(echo_pcb, echo_accept);
Connection is closed by the server after each echo session, like this:
void
echo_close(struct tcp_pcb *tpcb, struct echo_state *es)
{
tcp_arg(tpcb, NULL);
tcp_sent(tpcb, NULL);
tcp_recv(tpcb, NULL);
tcp_err(tpcb, NULL);
tcp_poll(tpcb, NULL, 0);
if (es != NULL)
{
mem_free(es);
}
tcp_close(tpcb);
Documentation says that tcp_close will free pcb structure. All of the callbacks that are used for tcp server are registered with this structure.
But when client sends new packet and starts a new connection, accept callback is called! Even though tcp_accept(echo_pcb, echo_accept); (i.e. callback registration) is done only once in the init function and that echo_pcb structure is already freed after tcp_close.
So I'm confused. Why all the other callbacks are registered multiple times but accept is registered only once? Is it okay to do it like this?
Okay, so according to this answer to the same question on the lwip mailing list, that is correct behaviour. tcp_accept registers callback for a port and it won't be unregistered when tcp_close is called.
When trying to use a callback function for a DBus reply I get stuck on creating a good/well working main loop.
What I want to do is simple, make a DBus call and specify a function which should be called when the reply comes. This is because I do not want to block my thread for the whole time until a reply has been calculated and arrived.
I first use dbus_connection_send_with_reply(..) to get a DBusPendingCall, then i specify a callback function using dbus_pending_call_set_notify(..). Before doing this, when connecting to the bus, I have started another thread which should wait for a response and call the callback functions. I have found no examples at all and no very good documentation of how I should design a dbus main-loop like this. I have tried:
// Main dbus loop handling data transfer and callbacks..
void *dbus_main(void *args)
{
my_dbus dbus = (my_dbus)args;
while (MY_DBUS_STATUS_STOPPING != dbus->status
&& dbus_connection_read_write_dispatch(dbus->conn, -1))
;
return 0;
}
// Start the dbus main loop in a new thread
void dbus_main_start(my_dbus dbus) {
if (!pthread_create(&dbus->th, NULL, dbus_main, dbus)) {
// PRINT ERROR
}
}
My problem is two things:
I try to stop the app by setting the dbus->status flag to MY_DBUS_STATUS_STOPPING and waiting for the threads to join. This does not work if the thread is blocked in the dbus_connection_read_write_dispatch(..) function. If i want the app to stop fast then I need to specify a very short timeout. Can't I wake the blocked thread in some other way?
More seriously, with this code i don't get any callback from the method I call. If I add some fprintf(..) to write to stdout I might suddenly get my callback. It seems quite random, so maybe some kind of deadlock? I have tried having a dbus_connection_flush(..) between sending the message and adding the callback with _set_notify(..) function. Doesn't do any difference... But printing some letters to stdout in the same place fixes the problem. Printing to stdout in the dbus-main-loop insted of an empty ";" seems to do the trick sometimes...
So anyone who has an example of using the low-level dbus api together with async methods, ie not using _block(..)??
You can create a simple DBus application as follows...
To setup a server to handle incoming messages, call dbus_connection_register_object_path passing in a VTable containing function pointers to handle the messages. Such as:
{ .unregister_function = UnregisteredMessage, .message_function = ServiceMessage }
To send a new message, call dbus_connection_send_with_reply and then dbus_pending_call_set_notify to associate a callback function to handle the reply.
Next you will need to service DBus. This can be done in a separate thread or by calling periodically with non-blocking calls in the same thread, as shown below:
/* Non-blocking read of the next available message */
dbus_connection_read_write ( MyDBusConnection, 0 ) ;
while ( dbus_connection_get_dispatch_status ( MyDBusConnection ) == DBUS_DISPATCH_DATA_REMAINS )
{
dbus_connection_dispatch ( MyDBusConnection ) ;
}
There are some good example of using the DBUS C API here: http://www.matthew.ath.cx/misc/dbus
It is highly recommended that you use a D-Bus library other than libdbus, as libdbus is fiddly to use correctly, as you are finding. If possible, use GDBus or QtDBus instead, as they are much higher-level bindings which are easier to use. If you need a lower-level binding, sd-bus is more modern than libdbus.
If you use GDBus, you can use GMainLoop to implement a main loop. If you use sd-bus, you can use sd-event.
For an application in C, i need to response more than one clients.
I setup the connection with a code like,
bind(...);
listen(...);
while(1){
accept(...);//accept a client
recv(...);//receive something
send(...);//send something to client
bzero(buf);//clear buffer
}
This works great when i have only one client. Other clients also can connect to the server but although they command something, server does not response back to clients who connected after the first client. How can i solve this problem?
Write a server using asynchronous, nonblocking connections.
Instead of a single set of data about a client, you need to create a struct. Each instance of the struct holds the data for each client.
The code looks vaguely like:
socket(...)
fcntl(...) to mark O_NONBLOCK
bind(...)
listen(...)
create poll entry for server socket.
while(1) {
poll(...)
if( fds[server_slot].revents & POLLIN ) {
accept(...)
fcntl(...) mark O_NONBLOCK
create poll and data array entries.
}
if( fds[i].revents & POLLIN ) {
recv(...) into data[i]
if connection i closed then clean up.
}
if( fds[i].revents & POLLOUT ) {
send(...) pending info for data[i]
}
}
If any of your calls return the error EAGAIN instead of success then don't panic. You just try again later. Be prepared for EAGAIN even if poll claims the socket is ready: it's good practice and more robust.
i need to response more than one clients.
Use Threading.
Basically you want your main thread to only do the accept part, and then handle the rest to another thread of execution (which can be either a thread or a process).
Whenever your main thread returns from "accept", give the socket descriptor to another thread, and call accept again (this can be done with fork, with pthread_create, or by maintaining a thread pool and using synchronization, for instance condition variables, to indicate that a new client has been accepted).
While the main thread will handle possible new clients incoming, the other threads will deal with the recv/send.