I have an existing library in C, which I want to be able to allow remote access to (either from Linux or Windows).
I looked at the usual RPC suspects like Thrift and Protobuf, but neither of these deal cleanly with C-style function calls (things like pass-by-ref, char* instead of string, * instead of List<> etc).
In short, to use either of these it looks like I would need to write a complete IDL from scratch, and add a lot of boilerplate code to transfer C-style function calls into these environments.
Are there any RPC libraries around that
can deal directly with C header files (or have tools to auto
generate the initial IDL from C definitions)?
are cross-platform Linux/Windows compatible?
require the absolute minimum of boilerplate code?
support sockets
are relatively high performance (XML-RPC i'm looking at you)?
Well, there's protobuf-c, an implementation of protobuf in C.
And then there's the classical XDR, found on most/(all?) unix-like systems, versions exist for windows as well. See also the Linux xdr(3) man page which contains an overview of the API.
Note that both protobuf and XDR are serialization libraries, they don't provide RPC. The "companion RPC library" to XDR is called, well, RPC, but I don't think anyone writes new code with that, and AFAICS it's unix-specific (portmap doesn't run on windows, does it? And it's generally a bad idea anyway.). Then there's protobuf-c-rpc which is the C version of the protobuf RPC library; probably a better bet than classic RPC.
Related
gcc (GCC) 4.7.2
PJ SIP 2.1
Hello,
I am developing an application that will use the PJSIP API.
Just looking at the API documentation and I see some functions that seem to be just wrappers for the standard C library. i.e. pj_memset, pj_strncpy, pj_strlen, etc.
I can see some alternatives that might be worth considering pj_strncpy_with_null() which will always NULL terminate a string. A another advantage could be is that the pjsip uses a pj_str_t structure to store the string and the size. Which could be better than using a normal C string.
And is there any point using pj_size_t over size_t which is portable anyway?
The link for quick reference is here:
http://www.pjsip.org/pjlib/docs/html/group__PJ__PSTR.htm
It there any real advantage using PJSIP over the standard C library?
Many thanks for any suggestions,
Short answer: Use the PJSIP API (all of it).
Long answer: It depends.
If you were programming an application for standard Desktops, that is, x86/x64 Windows/Mac/Linux, then no, it wouldn't really matter too much if you used the standard C library or wrappers like the PJSIP functions. Practically, of course, there might be functions that take (as you pointed out) the pj_str_t struct instead of a char *; it would be easier then to use the PJSIP API just to simplify and remove the need for conversions.
The reason for wrappers, I'm assuming, is to make it easier to develop on embedded devices. I don't mean just ARM or other non-x86 processors—though it could apply there as well; I mean custom embedded devices: things that have a very specific purpose and change infrequently. These embedded devices have very limited capabilities and sometimes even lack an OS. Without an OS, these processors might not have a malloc function or the like. Frequently, the libraries associated with the devices, since they are customized so much, are not entirely "standard" and differ in some small way. By having wrappers for everything, PJSIP can avoid most issues and even provide implementations across the board for things such as strcpy or malloc such that all devices run the "same" code.
Wrappers also provide the means for "hooks." Hooks enable better error messaging (and possibly handling). It's unclear whether PJSIP is doing this (I have never used PJSIP—I am talking from experience using other frameworks), but I am pointing it out just to show why a framework might bother wrapping everything.
In the end, it boils down to your purpose: if you chose to use PJSIP in the first place, then I would go all out and use all of its API. If you are only using it in a few places (for whatever reason) then it probably doesn't matter. Again, it appears that PJSIP is targeting embedded devices (it lists Nokia and even RTOS systems), where it is fairly common to provide wrappers for even "standard" functions. If this is the case, and you are using it in this way, definitely use the entire API.
Will you be sticking with pjsip?
PJSIP source code ("The Software") is licensed under both General
Public License (GPL) version 2 or later and a proprietary license that
can be arranged...
If you think the GPL may be too restrictive for future expansion (such as Android's no-GPL-in-userspace policy) and their proprietary license is not acceptable, you may benefit from using your own portable code/wrappers that you could use with a less restrictive BSD stlye library like Baresip
There are plenty of other methods to provide needed functionality where the standard C library does not support it, many of which will be better tested (I hate to mention autotools, but... it does support most platforms - some would say too many) Or you could include implementations/adaptations from musl-libc
Another thing to consider is the C api is based on standards and fairly set in stone while the wrappers in a given project are much more free to break API compatibility from version to version (just ask a glib/gtk programmer)
I'm looking for a "core" C cross-platform toolbox, because I need lots of "useful" functions (read/write ini files, network routines, arrays, lists...)
I was thinking about GLib, may be Qt (the core part) but I would appreciate a pure "C" stuff
I think glib is a fantastic choice, but it's perhaps somewhat less widely scoped than what you're after, there is no networking in glib as far as I know.
For that, you need to add GIO from the same family of libraries.
Apache Portable Runtime (APR) may be the solution you are looking for. It is used, among other projects, for the Apache http server and Subversion.
I think glib is great. It comes with a great deal of core algorithms and data types. There are many libraries build around GLib and GObject. You have indeed GIO for all kinds of different input and output on files, over network etc (will remind you a bit of the Java like IO operations), and you gtk for Gui applications. All These libraries were designed with portability in mind and extendibility to other languages (eg. python, perl etc). But learn to use GOjbect as well, because the best work comes from using these libraries ( http://www.gtk.org/documentation.php ) together.
We are on designing a software in C(just C) need buffer structure in some part of that.
But I do know how to choose a good one?
Actually our program is open source and we need an open source and efficient buffer and queue library in C to implement this part.
Thanks for your helps.
you can use this container library :
https://github.com/jacob-navia/ccl
its from eccentric genius jacob navia (if you are not regular at comp.lang.c you will not understand it). But the thing is the library is quiet efficient and unusually "EXCELLENT" manual. The Documentation will surely buy c coders.
It has most common data structures like lists/queues/deques/circular linked lists etc/etc.
Consider using libevent. The newer version comes with a buffer interface suitable for the event framework that libevent provides. From their web page:
Libevent additionally provides a sophisticated framework for buffered network IO, with support for sockets, filters, rate-limiting, SSL, zero-copy file transmission, and IOCP. Libevent includes support for several useful protocols, including DNS, HTTP, and a minimal RPC framework.
I'm attempting to utilize the socket.h functions within Windows. Essentially, I'm currently looking at the sample code at https://beej.us/guide/bgnet/html/multi/clientserver.html#datagram. I understand that socket.h is a Unix function -- is there anyway I can easily emulate that environment while compiling this sample code? Does a different IDE / compiler change anything?
Otherwise, I imagine that I need to utilize a virtualized Linux environment, which may be best anyways as the code will most likely be running in a UNIX environment.
Thanks.
You have two options:
Use Cygwin (Unix emulation library).
Port to Winsock (Windows standard library).
Cygwin: lets you compile your Unix sources mostly untouched, but ties you to the Cygwin emulation library. This have two implications: general performance -no only network- will probably be less than optimal; and the target environment must have (at run time) the Cygwin DLL installed.
Winsock: this requires you to replace sys/socket.h (BSD sockets library, UNIX standard for the TCP/IP stack) with winsock2.h, and rewrite some parts of the code - not much, but some.
Some related questions with valuable info:
Differences between winsock and BSD socket implementations
Some Issues About Cygwin[Linux in Windows] (socket,thread,other programming and shell issues)
Examples for Winsock?
I think you are looking for Winsock library.
Writing cross platform network applications is not easy with what the BSD standard provides you. Sure it will work but you'll have to make some replacements like replacing ioctl (if needed) with ioctlsocket (on windows). More differences here.
My advice is to use a library that hides these ugly differences and provides a unified way of communicating. I personally use ACE. You have plenty of examples that show you how to create a server and a client. Copy from the samples and see how they do it there. Their mailing lists are of great help also (don't forget to use the PRF - see the source tree for the Problem-Report-Form). You can borrow the books for more information. Important note: by using ace you can use ACE wrapper functions like socket, setsockopt, ioctl etc. without worry that they will not work. Unfortunately this adds a library dependency which is not always an option. But ACE has more powerfull features which I'm sure you'll like once you discover them. Hints: Reactor, Proactor.
Is there a standard way of reading a kind of configuration like INI files for Linux using C?
I am working on a Linux based handheld and writing code in C.
Otherwise, I shall like to know about any alternatives.
Final update:
I have explored and even used LibConfig. But the footprint is high and my usage is too simple. So, to reduce the footprint, I have rolled out my own implementation. The implementation is not too generic, in fact quite coupled as of now. The configuration file is parsed once at the time of starting the application and set to some global variables.
Try libconfig:
a simple library for processing structured configuration files, like this one: test.cfg. This file format is more compact and more readable than XML. And unlike XML, it is type-aware, so it is not necessary to do string parsing in application code.
Libconfig is very compact — a fraction of the size of the expat XML parser library. This makes it well-suited for memory-constrained systems like handheld devices.
The library includes bindings for both the C and C++ languages. It works on POSIX-compliant UNIX and UNIX-like systems (GNU/Linux, Mac OS X, Solaris, FreeBSD), Android, and Windows (2000, XP and later)...
No, there isn't one standard way. I'm sorry, but that is probably the most precise answer :)
You could look at this list of Linux configuration file libraries, though. That might be helpful.
Here are four options:
Iniparser
libini
sdl-cfg
RWini
If you can use the (excellent, in any C-based application) glib, it has a key-value file parser that is suitable for .ini-style files. Of course, you'd also get access to the various (very nice) data structures in glib, "for free".
There is an updated fork of iniparser at ccan, the original author has not been able to give it much attention over the years. Disclaimer - I maintain it.
Additionally, iniparser contains a dictionary that is very useful on its own.
If you need a fast and small code just for reading config files I suggest the inih
It loads the config file content just once, parse the content and calls a callback function for each key/value pair.
Really small. It can be used on embedded systems too.
I hate to suggest something entirely different in suggesting XML, but libexpat is pretty minimal, but does XML.
I came to this conclusion as I had the same question as you did, but then I realized the project already had libexpat linked-in--and I should probably just use that.