I wanted to know if there is any library which does the job of libCURL in FreeBSD kernel. I know libCURL is a user-space library but was looking for something similar in kernel. Porting is one option but i think it surely will not be a straight forward thing.
Any leads on the above query would be great!
Thanks!
No, there isn't. HTTP is not implemented in kernels by ordinary operating systems, neither clients nor servers. Even though there were once experiments with a http server in the Linux kernel..
Related
I just have a simple question. I am a student and I am learning. I am not very proficient at C++, but I finally set up a working http reqest app in c++ using winsock and I just wanted to know that after compiling will the http request still be sent from other OSes that don't have WinSock?
WinSock, or at least the parts you probably will have been using for introductory networking stuff, is based off of, and largely compatible with, the BSD socket API, which is available on all current operating systems. If you don't have experience with cross-platform development it's unlikely that your code would compile the first time through on a Linux system, but the underlying techniques would be the same.
For cross-platform networking, you might want to consider something like Qt, which provides an API which will work mostly the same on all OSes without much per-platform stuff. Its networking API is also based off Berkeley sockets.
In general, though, there's just no way of checking that your code works cross-platform without testing it cross-platform. Grab a Linux distribution and try it out; note that some are specifically intended to work from your Windows disk without the need to repartition.
If you use standardized BSD-based socket functions, then your code will typically work on multiple platforms socket(), bind(), connect(), send(), recv(), etc. Caveats include:
error codes. When a WinSock/BSD function fails on Windows, the error code is retreived using WSAGetLastError(), whereas other platforms use errno instead. So you will have to wrap that portion if you are trying to write cross-platform code.
get/setsockopt() may implement different options on different platforms, not all options are standardized across all platforms.
If you use WinSock-specific functions, then your code will only work on Windows. WSASocket(), WSAConnect/Ex(), WSASend/Ex(), WSARecv/Ex(), etc.
All versions of Windows have WinSock. Most platforms, including Windows, support a BSD-based socket API.
After you compile your code, it will only run on the specific platform it was compiled for. You would have to compile the code separately for each platform you want to support.
I have a C++ (technically MATLAB mex) program, which I am planning to use to launch a stand-alone pure C++ slave program on my system. The master calling program may look something like the following:
void mexFunction(int nlhs,mxArray *plhs[],int nrhs,const mxArray *prhs[]){
system ("path/to/slave/program");
}
Once the slave is launched, I would then like to have a second mex program which will communicate with and send data to the slave program. The data sent will be in the form of large-ish C++ arrays.
I imagine that I will need some kind of handle to the slave program (perhaps its pid?), a method for sending messages and presuamably a way for the slave program to listen out for incoming messages.
I have no experience in getting separate C++ programs to communicate with each other, so any hints in this area would be appreciated. In addition, if there are any specific MATLAB mex-specific caveats, I would be interested to hear about these.
EDIT: I should have mentioned that I am building this on Ubuntu, but will ultimately like it to work on all platforms. Platform specific advice very welcome, but multi-platform ideas are really what I'm after.
You are looking for an IPC (Interprocess Communication) mechanism.
Boost has an entire chapter on this and is a cross-platform solution.
Boost.Interprocess has been tested in the following compilers/platforms:
Visual 7.1 Windows XP
Visual 8.0 Windows XP
GCC 4.1.1 MinGW
GCC 3.4.4 Cygwin
Intel 9.1 Windows XP
GCC 4.1.2 Linux
GCC 3.4.3 Solaris 11
GCC 4.0 MacOs 10.4.1
If you have time, as suggested in previous answers, you should definitely go for IPC.
However, there is also many "quick and dirty" solutions, where you don't need to spend time reading any documentations.
The one I can recommend you, is to use files. When you want to communicate, Process 1 write down a file with the arguments. And then another file to say that the arguments are ready. Process 2, have a loop waiting for this second file. If it finds it, it remove it and then read the arguments.
I know this is dirty, but this is very fast to program, and no need to read any documentations.
If you have large arguments, and you would waste a lot of time writing them on the hard disk. I suggest you something even dirtier: mounting the RAM, and writing on it:
mkdir -p /tmp/ram
sudo mount -t tmpfs -o size=512M tmpfs /tmp/ram/
I highly recommend COM technology for all Windows communication.
http://www.microsoft.com/com/default.mspx
By the way, if you want to use Matlab code directly, you can compile COM component using Matlab Builder NE, so you don't need to write mex at all.
If you're looking for a cross platform solution for communication checkout boost::interprocess. The documentation also has quite a bit of information about how these things work.
This is platform specific, but on a POSIX platform you can use popen(3) to launch a command, giving you a pipe you can use to write data to its standard input (and also read from its standard output).
More portably, but less simply, the Boost.Interprocess library has all sorts of ways of communicating between processes.
I have a Linux C++ application which run as a daemon. When user executes this application, it will be running in the background, listening on a port, and waiting for connection from the clients.
Is it possible to port this kind of application to Windows platform using Cygwin or MinGW?
Thanks.
Cygwin aims at POSIX/Linux source level compatibility, so your application is supposed to build and work there with no or only minor modifications.
MinGW does not try to provide such a compatibility layer. It's just the GNU toolchain for Windows, so you would need to replace any uses of POSIX/Linux-specific APIs with Windows equivalents.
It is possible to port almost anything (unless it makes sense only to one OS). The question is, "how hard is it to port application X"? And to help answer that question, we need to see source code.
General purpose tips
It basically boils down to how much compiler/system-dependent code you've spread out over your code base. I see you're using at least two things that are sensitive: daemons and sockets.
Daemons are tricky to port as the equivalent on Windows (a windows service) requires different platform-specific code. This is fixed cost (e.g. does not vary on the size of the rest of the application).
Sockets are more or less tricky to port depending on whether you're using advanced networking features (asynchronous I/O, etc.), which tend to vary more from system to system. It also depends on whether you abstracted socket manipulation code into some re-usable component. Windows supports a very similar sockets interface (the classic BSD socket interface with minor modifications to random parts of the API). Changing one Socket class is easier than changing your code if you didn't write a wrapper class.
I'm looking for a simplest (and fastest) example of TCP socket programming for windows, c or c++, whichever can get it accomplished faster, sending trival data, for example 1 byte, or several bytes, but in one packet. It's for research purposes. I googled and found several examples, however every single of out them looks a bit different, some are in C, some are in C++, some use ZeroMemory (from windows), some use memset, some of them assign data in different ways, so while I can find examples of winsock in c/c++ and while I'm not an expert in socket programming - I'm not sure what's the absolutely minimalistic c/c++ code to get it accomplish in a fastest way possible.
I know that UDP would be much faster, but it needs to be reliable at the same time, hence I'm looking for TCP.
I guess I could try each of them and try to time them, but was wondering if some socket/winsock expert here would have a super simple server/client in C/C++ with some timing function (high resolution) at the end.
I say super simple, because I'm trying to determine how fast (and the fastest way) can socket transmit on my machines, of course it can include turning off Nagle's algorithm, which is what I would like to do anyway. I'm not sure what other tricks people use.
Thanks.
Try Len Holgate's socket server framework. I believe he has commercialized this in a packaged version but this should be a good place to start. There is a client implementation tutorial included. This is not the simplest code but if you are interested in maximizing performance, simple code may not meet your needs.
You will have to add your own timing support, but that's likely true for any possible off-the-shelf package.
Boost Asio is probably your best bet. it's a very good library with timing support and everything you should need to get going.
edit: I know that this isn't a pre-built client/server which is exactly what you are looking for, but Asio makes it extremely easy to get what you want out of a few lines of code.
The most minimal examples of which I am aware are in Beej's Guide.
If you want an off the shelf product, look at any of the messaging products available. They require the least amount of coding to get going, typical examples are:
Open Source:
OpenDDS - based on the DDS protocol (very high performance - used in things like submarine, ship control systems etc.) Their implementation is slightly slower than raw boost::asio, however for ease of use and the bells and whistles, hard to beat.
ZeroMQ - similar to DDS, but based on the MQ protocol, again very fast (millions of messages/sec), MQ is established, but ZeroMQ is not there yet.
AMQP - I believe you'll be able to find something from Red Hat in this space, again very fast, and a new protocol.
Commercial:
Tibco RV: hard to beat, except by hardware vendors
29West - hardware (and software - thought I've never personally played with it)
Solace - hardware
Tervella - hardware
The last three assumes you've got a few million bucks lying around! ;)
Before writing the third comment, I collect them in an answer
There's RUDP which is reliable and fast since it omits the connection setup: en.wikipedia.org/wiki/Reliable_User_Datagram_Protocol ; see also What do you use when you need reliable UDP?
Out of Steven's UNIX Network Programming I, p. 369 I suggest T/TCP which is implemented at least for FreeBSD: http://www.manpages.info/freebsd/ttcp.4.html
I've just implemented a network solution using socket++, and it works pretty well. I believe that it's the basis for boost asio, so if you don't want to install all of boost, you can check it out.
The point of the library is that you can use a stream with your socket, sending data as you would to std::cout or std::cerr.
EDIT: if you're using more recent versions of windows, then this library would need some tweaking to compile (it works fine as-is for XP, but apparently some networking code got moved around for win vista and 7).
You can check Push Framework.
ucspi-tcp
Oldie but goodie, written in C, qmail is widely used mail server is based on it.
https://cr.yp.to/ucspi-tcp.html
I'm designing a training program in C++ that will be distributed to a large number of facilities, most of which won't have much in the way of an IT staff. The program connects via a TCP connection to a central database which stores various pieces of data for research and evaluation purposes.
The problem I have is that I would like to make the transmission secure, and the most commonly recommended way to do that seems to be OpenSSL - which seems all well and good, but I've got a problem. As I understand it, OpenSSL must be installed specifically on each of the systems. The facilities won't have the expertise required to compile and install the source on their systems, the computers will be sufficiently varied (all Windows boxes, but of varying make and quality) to rule out distributing a specifically-compiled binary, and continent-wide distribution makes it impossible for my team to personally set it up.
Does anyone have a recommendation for how to solve this problem? Am I simply incorrect in my assumptions, and one can distribute it without installation? If not, is there a more practical alternative?
As long as all your machines are XP+, with two versions of OpenSSL you should be ready, one for 32bits and one for 64bits. Just provide two separate installers and that should be it. There's no need to compile for each machine.
Just remember to include the Visual C++ redistributable package in your installer as well.
If you have to support ancient Windows versions, it gets a bit more complex but not that much.
Actually, OpenSSL seems like a good option based on what you described.
From what I understand of OpenSSL, it is a library written in C (with wrappers around it for other languages), meaning that you can include it in the code base of whatever it is you are writing.
I'm pretty sure that it is not a program that has to be installed, so I think that you shouldn't have to worry about that.
You might also like to experiment with IPSEC- if you are concerned with distribution of binaries etc to client machines, IPSEC could be interesting solution. Since virtually all Windows boxes support it, all you have to do is to configure IPSEC policy on DB server - by making it as "required" this way, all the data between client machines and DB server will be encrypted.