I'm searching for an efficient solution to make a C Freebsd platform communicate with a Node.js server.
Here are my requirements:
the client must be able to send binary streams and text messages (typically JSON messages)
those messages can be multiplexed: for instance, a text message can be sent while a binary stream is being sent.
I was heading to the libwebsockets library, but it seems to be a half-dead project, no multiplexing extension support, for instance.
I thought to implement a TCP/IP solution myself.
Related
So I've created a simple chatserver / chatclient in C. The chatclient reads from stdin and outputs to stdout. The goal is to adapt this to a frontend web UI. I was thinking of using React and it seems like the most commonly used socket libraries are socket.io or Websockets.
So my big question is: can I replace my chatclient I've built in C with a React chatclient that uses socket.io or Websockets to connect to my chatserver in C?
Are the two sockets compatible?
The answer is both "Yes" and "No", but the answer given by justcivah probably should have been "No", since it lacks vital information (edit: the referenced answer was deleted)...
The reason is that WebSockets is a protocol, so your server needs to understand that specific protocol.
The WebSockets protocol usually runs as an additional layer over TCP/IP sockets (which is the only layer you probably have on your C chatserver), and it includes additional ("header") data before the "message" (payload). WebSockets also require an HTTP based handshake (though other possible handshakes might be added in the future).
There are a number of different WebSocket libraries in C that could help you implement the WebSockets protocol in your C chatserver - just search for C WebSocket Framework or something like that.
Do you know of any HTTP client library in C (with SSL support) that also allows direct communication with the remote server?
I have a client-server application where the client uses HTTP to start a session in the server and then tells the server to switch the connection from HTTP to a different protocol. All communication is encapsulated in SSL. It is written in Perl and works well, but I'm looking into implementing the client in C.
I know libcurl gives you access to the underlaying socket but it's not enough because of the SSL requirement.
Notice that libcurl doesn't do the SSL part by itself, it uses OpenSSL. So, if you can get the socket handle from libcurl after the first HTTP interactions, AND the session key it uses (some spelunking required) you can go on directly with OpenSSL from that point.
I think that you must be looking for this otherwise you must have to write it yourself, like this
Sounds like you want Web Sockets. Don't know if there's a C library available though. I would assume there is, if you dig.
I want to implement a Unix daemon (let's call it myUnixd), and want the user to be able to interact with this daemon via the command line, for example:
myUnixd --help # will display help information
myUnixd --show # will show some data (the's deamon should be doing the work)
So my question is: How can I communicate with the daemon? I was thinking about Unix domain sockets. Can someone tell me the right way to do this?
Thanks.
Use Berkeley sockets. Specifically, you can create a "UNIX domain socket" (otherwise known as a "local domain socket," which will create what looks like a text file. Write to the text file to send text to the daemon, read from it to receive text from the daemon. You can implement this with a few function calls.
If you want something more advanced, you can also use DBus, which offers a more sophisticated interface, but which is more complicated to learn.
use tcp socket if you want to use telnet to communicate with your daemon.
One could also use Remote Procedure Call (RPC) for such client-server communication. There are different types of messages (protocols) that can be used together with it, one of them is JSON.
The JSON-RPC protocol is very well accepted for such tasks. You can find different tools and libraries to embed in your software. A quick search on google gives this C library. The advantage of such libraries is that from a JSON specification file, where you define all your remote function calls, it creates client and/or server stubs that you can just use in your code out of the box.
As a listener one can use sockets, as the other responses state, or just an embedded HTTP server like microhttpd (and libcurl for the client). There are plenty of examples out there to just reuse. HTTP allows you also to run your client behind a proxy.
i have a program that receives data from a wireless device over bluetooth...i now need to do some operations in the data and then send it to the website (web server!!!) as a .csv file...i also need to authenticate the device itself from it hardware address which is also obtained in the program.i am coding this in gcc linux compiler using C...can anyone tell me how do i go about doing this?
You should look into the LibCurl library. It handles uploading via HTTP and a number of other protocols.
I need to decode a packet sent using TIBCO-RV and pull fields out of the header and skip over the message body. I have not been able to any examples or documentation. Does anybody know of any open source applications that might do this or if there is a Wireshark dissector out there somewhere?
Maybe you should try applying for a license and getting the official documentation. According to Wikipedia:
TIBCO provides messaging APIs in C,
C++, Java, Visual BASIC , Perl and
.NET to receive data feeds on MS Excel
spreadsheets and other applications of
choice.
Failing that, you could perhaps dive into the TIBCO:RV Perl module.
The methods which TibcoRV implements reliable mutli-cast are propriety, but one would assume easy to reverse engineer. I don't believe any of the official documentation goes into detail on the packet level detail. It's quite easy to get the data out if you have the API.
Several things come to mind:
Is the client on your machine running? This is required in order to create the multicast subscription (unless you are using broadcast mode). Otherwise, you need to have some client subscribe to the multicast channel, or your switch shouldn't forward the traffic.
Generally, you will have a single rrd running locally. You have TCP traffic between the RRD and your app. You can use an app like socketsniff to view the traffic between the two.