I want to write a C program that can search Bonjour enabled devices on network.
Basically we have a Network IP Camera, it supports Bonjour protocol. I want to write API in C that can search these devices which have Bonjour enabled. Does anyone have sample code or suggestions on how should I do that?
The following links provide some code samples, as you requested:
mDNSResponder
Quotes from mDNSPosix/ReadMe.txt:
mDNSPosix is a port of Apple's Multicast DNS and DNS Service Discovery
code to Posix platforms.
Multicast DNS and DNS Service Discovery are technologies that allow
you to register IP-based services and browse the network for those
services.
Packing List:
The sample uses the following directories:
o mDNSCore -- A directory containing the core mDNS code. This code
is written in pure ANSI C and has proved to be very portable. Every
platform needs this core protocol engine code.
o mDNSShared -- A directory containing useful code that's not core to
the main protocol engine itself, but nonetheless useful, and used by
more than one (but not necessarily all) platforms.
o mDNSPosix -- The files that are specific to Posix platforms: Linux,
Solaris, FreeBSD, NetBSD, OpenBSD, etc. This code will also work on
OS X, though that's not its primary purpose.
o Clients -- Example client code showing how to use the API to the
services provided by the daemon.
Using the Sample
---------------- When you compile, you will get:
o Main products for general-purpose use (e.g. on a desktop computer):
- mdnsd
- libmdns
- nss_mdns (See nss_ReadMe.txt for important information about nss_mdns)
o Standalone products for dedicated devices (printer, network camera,
etc.)
- mDNSClientPosix
- mDNSResponderPosix
- mDNSProxyResponderPosix
o Testing and Debugging tools
- dns-sd command-line tool (from the "Clients" folder)
- mDNSNetMonitor
- mDNSIdentify
SDWrap
ReadMe:
Quite simple wrapper app to execute some command with Zeroconf
supplied addresses and ports. Uses wxWidgets and wxServDisc for
service discovery...
Good luck!
Related
I'm doing an embedded-system project now. From my view, AT commands can be sent to a device to retrieve 4G information, dial and so on. On the other hand, we can also do that by calling APIs provided by the 4G vendor.
My question is what's the relationship between them? Is the API a wrapper for the AT commands?
TL;DR
Vendor's API (not only C, but also C++, Java or Python depending to the vendor and the modem model) can both be wrappers for AT commands and a wider, more powerful set of API were the user can port complex applications.
It depends on the vendor and on the model.
A jungle of modems produced by different vendors
It is impossible to define a general "rule" about API provided by a Cellular Module (not necessarily a 4G module).
First of all every vendor usually implements standard AT Commands (both Hayes commands and extended standard commands for cellular devices). In the same way every vendor has it's own implementation of the user application area where the customers can store their own application to control the modem's functionalities and to use them according to their own application requirements.
AT commands remain the interface to be used when the modem needs to be connected (and driven) by an external host. When the user application area is used, instead, a wider set of API is usually provided. They may include:
A library exporting a subset of the OS capabilities (threads management, events, semaphores, mutexes, SW timers, FS access and so on)
A library offering the capability to manage the specific HW of the device (GPIOs, SPI, I2C, ADC, DAC and so on)
A library offering a programmatical way to perform action, related to connectivity, that would normally be executed through AT commands (registration status check, PIN code insertion, PDP context activation, SMS management, TCP/UDP/TLS sockets)
The latter usually access a base layer involving all the functionalities provided by the modem. Usually this is the same layer invoked by the AT commands sent through modem's serial interface.
Sending AT commands... from the vendor's API?
Of course it often happens that the library mentioned above provides just a subset of the functionalities usually exported with the AT commands set so, in order to "fill the gap", a further set of APIs is usually exported as well:
A set of functions that allow the simulation of AT commands sent to the modem's serial port. Sending them and parsering the responses they send in the vitual internal serial/USB interface allow the user to port in the internal user application area the the application they previously run on an external host processor (with obvious BOM benefits).
As an example, please check Telit Appzone here and here. It was the inspiration of my answer because I know it very well.
I don't know why you name the title that there's a relationship between AT command and Linux-C API.
Regarding AT command, you can take a look at this wiki article for general information.
Each module has a specified AT command sets. Normally, the module manufacture just offers AT command set and what return values are.
Is API a wrapper of AT command?
If you can use the API provided by the manufacturer, then yes, it's a wrapper of the AT command handler.
My question is what's the relationship between them? Is the API a wrapper for the AT commands?
It is impossible to be sure without having any details of the device, but probably any C API for it wraps the AT command set, either by communicating with the device directly over an internal serial interface or by going through a device driver that uses AT commands to communicate with it.
However, it is at least conceivable, albeit unlikely, that the 4G device offers an alternative control path that the C API uses (definitely via a driver in this case).
I'm not quite sure what the point of the question is, though. If you are programming the device and its 4G component in C, and the manufacturer has provided a C API, then use it! If you are programming in some other language then at least consider using the C API, which you should be able to access from most other languages in some language-specific way. You should not expend effort on rolling your own without a compelling reason to reject the API already provided to you.
I am currently working with an embedded FOX G20 V board with an ATMEL AT91SAM9G20 processor. I am hoping to be able to establish a connection by ethernet between this board, and a linux machine. The protocol of communication is using the uIP library (smaller implementation of TCP/IP intended for embedded boards).
Anyway, I've downloaded the developpment kit offered by the processor, and it has countless examples of different types of communications, one of which includes a hello world program.
However, at this point, even with the example, I'm relitvely stuck. I am un sure which file of the hello world project it is I have to compile since there are many of them. Is it the main.c that is located in at91sam9g20-ek.zip\at91sam9g20-ek\packages\basic-emac-uip-helloworld-project-at91sam9g20-ek-iar.zip\basic-emac-uip-helloworld-project-at91sam9g20-ek\at91sam9g20-ek\basic-emac-uip-helloworld-project\ or is it another file?
The whole point is to get a communication established by the board and the remote host (in this case my Linux machine), and send it "hello world" through ethernet. I am guessing that the application in this case defines its register addresses in which the board will be able to receive the connection from the remote host (I may be wrong).
In any case, I am hoping to get help by any "experts" that are familier with the project that may guide me, or explain to me how exactly to build this application they have provided.
I'm not familiar with this board but according to this link the application is supposed to start a telnet server (on port 1000) and an http server. I suggest that you look at the output on the serial link (to get the IP of your board, let's assume 10.159.245.156 as in the example), and if you get what is expected then you can try to telnet to your board:
telnet 10.159.245.156 1000
The kit gives you project file for three toolchains (IAR 5.4, Keil and GNU). You'll have either to open the correct one depending on your toolchain (which one do you use?), or adapt if you use another one.
Edit: You apparently use the IAR toolchain, thus you need to open the *.eww file (for instance basic-emac-uip-helloworld-project.eww). This example only obtains an IP and displays statistics on the debug output (serial link?). There are other examples for a telnet or http server.
Moreover it's a detail but I think the emacs tag is irrelevant in your post. I think you confused EMAC (what is this?) and Emacs which is a popular text editor.
I have a requirement to have a cross-platform program --- intended for mobile devices such as Android, Brew, Bada, WinCE etc --- be able to communicate with other instances of itself via Bluetooth.
Unfortunately:
the Bluetooth APIs on such devices are all radically, radically different.
the terminology they use is also radically different.
what actually works is frequently radically different to what they say works.
So far I've discovered that Android will allow you to connect to or listen on RFCOMM services specified by a simple UUID, but does not allow more complicated manipulation of SDP records; Brew claims to support SPP but the API appears to allow arbitrary RFCOMM; Bada supports SPP but doesn't allow you to specify the UUID, so I have no idea how you're supposed to do service discovery or listen for two things at once...
Oh, and iOS doesn't allow Bluetooth communication at all to non-iOS devices.
So:
I can't be the first person to need to do this. Is there a known subset of Bluetooth functionality that I should be using in order to maximise portability?
Device makers usually implement some bluetooth profiles such as A2DP, OBEX, etc. Depending what you want to do, you should check that all your target devices implement the required profiles.
Note that even though a device can implement an specific profile, there may not be an API that will allow you to use it.
See http://en.wikipedia.org/wiki/Bluetooth_profile.
Where can I find an example program in C to print to a network attached HP printer.
Printing requires a printer driver which handles all the task of communication with the printer.
all you have to worry about is how to print, the fact that the printer is networked or usb or parallel doesn't matter
If you're hardcore and want to use the windows API (assuming you're on windows)
otherwise you could simply redirect output from STDIO like this article suggests
It depends how you want to talk to the printer. Nowadays a lot of printers can support many different network protocols to receive jobs. So which is it:
IPP (Port 631)?
LPR/LPD (Port 515)?
AppSocket (Port 9100 and others) ?
FTP? RCP? SCP?
Anyway, for most of these cases you can find example code here: http://svn.easysw.com/public/cups/trunk/backend/ -- Further help here: http://www.cups.org/documentation.php/api-filter.html
(However, I wonder why you want to implement such a thing yourself on Linux...)
Ideally, I would connect an Ingenico/VeriFone terminal to the net via an Ethernet cable, the terminal will exclusively run a program that I wrote. This program would poll a webservice, beep when it detects some kind of info, wait for somebody's input, transmit said info back to the webservice, and print a ticket.
Is this possible with terminals from Ingenico/VeriFone/someone else?
I'm looking for the form factor/semi-ruggedness of said terminals. We don't need/want something bigger like an PC or laptop.
I have built applications on Verifone, Hypercom and Trintech terminals. The Verifones are by far the easiest to devlop for. They have a simple flash and RAM file systems, apps are downloaded and run as files, the OS (Verix) is POSIX like with good C/C++ libraries etc. Only downside is tool cost, VerixV use ARM SDT (5K Euro per seat) and older Verix terminals (Coldfire based) use SDS compiler. Dev kit comes with default keys to sign your apps (not most secures, but you can password protect download access on terminal). I have written lots of apps on these terminals, not just payment app. Verifone multi-app controller (VMAC) is a crock of shit but it's very easy to run multiple apps yourself using pipes for inter-app comms (your apps won't run on third party terminals which use VMAC though). We used ethernet connectivity for FTP to manage app and config download as well as transaction batching. Also used WIFI on latest terminals for same (also used 3G terminals but I didnt do any of code on these). Verifone is PC-like in terms of code development and we shared lots of library/app code between WIN32/Verix/VerixV and Linux. Verifone terminals are well built and can take a lot of abuse but then most serious terminal manufacturers do a good job these days.