I have a system I want to test, the system handles a proprietary network protocol (this need to be checked). The tested protocols are over TCP and UDP.
I'm looking for a software I could install on my OS-X/Linux/Windows computer connect it to the system I want to test and inject protocol messages and analyse feedback (software should have the ability to compare for each received message if it is the expected one etc.).
Prefer a software with a nice looking GUI and open-source so I could add features if needed (could be a paid software).
Where should I begin?
There is a probably a library/framework which implements the protocol. My approach would be to use it (or write it when it's missing) to write simply unit tests.
There are many unit testing frameworks with nice GUIs, headless modes and automated tools, so unless you can be more specific, it's hard to suggest something.
With the Argos protocol analyzer (http://xpro.co/index.php/products/argos), you can:
define your proprietary protocol in XML
monitor IP traffic, offload to TCP/UDP endpoints, load proprietary
format text/binary logfiles
visualize the analysis
send commands/messages from command forms, where you can include also
a COM/ActiveX control, which can generate and receive traffic and
implement the logic behind it
Argos runs on Windows and it is a paid software.
Using Load Multiplier (loadmultiplier.com), you can test proprietary protocols. Any text / binary call flows (with / without media) over any transport protocol like (udp / tcp / tls / dtls / sctp / websocket / secured websocket) can be simulated using multiplier.
Disclaimer: I work for load multiplier tool.
Related
I was looking all over the internet to find a way to capture incoming packets from a certain network interface, then I came across PCAP, TCPDUMP, I believe the most commonly used networking library out there is Boost/Asio, so I wanted to use this library in order to capture traffic, but apparently there is no example for using Raw sockets or other classes to listen for incoming packets to a certain NI, I would appreciate any help or examples on this.
We eventually found out the best option for sniffing incoming packets was Libtins.
libtins is a high-level, multiplatform C++ network packet sniffing and crafting library.
Its main purpose is to provide the C++ developer an easy, efficient,
platform and endianness-independent way to create tools which need to
send, receive and manipulate network packets.
It uses a BSD-2 license and it's hosted at github.
How to make an external program control Tridium Niagara framework? I see two options; Which one is correct:
1) Niagara allows addition of 3rd party code to provide an API, and someone else has already done that and we can use it.
2) Niagara allows 3rd party code to do API but we have to write our own.
Niagara installations can be configured to process many different network control protocols driven by an external process across the network, for example by BACnet. The Niagara instance can be configured internally in many different ways to respond to control from across the network.
Niagara 4.x prominently features Web GUIs, including Javascript client widgets and server Javascript, or the server can respond to the Web GUI activity with its other configuration and scripting methods.
For any real complexity beyond the bundled network drivers or HTTP, 3rd party modules coded in Java are used. These would typically be coded as Niagara drivers, processing data over serial or sockets.
Niagara's APIs are mostly open. But Niagara is a complex environment. Completing Tridium's week-long developer training/certification is typically required to produce a proper module.
There are some external API's that Tridium built into AX. oBIX and Bajascript.
I've written external oBIX programs in both Java and Python to pull data from a remote Jace. You'll have to add the oBIX service and export the points you want to see.
Bajascript is a javascript library Tridium uses to interact with the system as well. I believe they released Bajascript 2.0 not to long ago. http://www.bajascript.com
If those don't do what you like, you'll more than likely need to write your own API to handle it.
I am attempting to build a client/server game architecture and would like to begin testing the game using my local Mac as the server. I have found several articles on Bonjour, but that is for local network traffic only. My goal is to make this application work over the Internet, connecting to a hosted application on a static address to facilitate turn data. However, I'm at a loss as to which Cocoa APIs to use for this purpose. Should I use NSConnection, NSStream subclasses, or good 'ol C sockets and whatnot. The game state is already built in Objective-C and is ready to be set in motion once I have the server facilities ready. Any insight?
NSConnection, NSStrean and C sockets are build for different needs. You need to specify the needs of your game and the kind of service in order to get more help. If you want to develop a client-server application that relies on the Internet and not on the local network, Bonjour will not be able to help.
C sockets, and Cocoa APIs that wrap around them are intended to operate on an open network stream between the client and the server. The advantage of having an open stream is that you can have the server send data to the client without the client having requested for it. NSURLConnection in Cocoa works differently. With it, you can perform HTTP requests and receive formatted responses from a server.
If your application is based on HTTP requests, I recommend you take a look an NSURLConnection, or AFNetworking, as a 3rd party alternative. If your application relies on open streams, I recommend you take a look at CFNetwork from Apple (C wrapper around BSD sockets that originates from the days Macs had Carbon, with great performance, stability and versatility) and GCDAsyncSocket, a 3rd party library wrapped around BSD Sockets, supports Crand Central Dispatch, is Objective-C ready, and does the job wonderfully.
I hope I helped.
I suggest you to use sockets, since they're not hard to use and are a standard way. I've even written an asynchronous wrapper class around BSD sockets: https://github.com/H2CO3/TCPHelper
This is for simple, one-to-one TCP protocol connections, supporting both IPv4 and IPv6. You can send and receive raw NSData and possibly build a protocol around it.
Foundation classes such as NSURLConnection are not particularily for this purpose; rather than to interact with standard HTTP servers (I suppose you don't want to implement a full HTTP server for a game).
NSNetServices may suit you just like CFNetwork, but the latter is a bit harder to use. If you'd like to use Foundation classes, I'd recommend NSNetServices.
Hope it helps.
There are many different ways to accomplish this. It really depends on how you'll be passing the data and what it will be used for.
First, I would setup a hostname that you can use for development purposes with your game. You can use anything like http://dyn.com/dns/ to setup this for your Mac. Then you can enable a compiler setting to switch out the development / production URL's.
Next, I would recommend using TCP sockets for your game (using CocoaAsyncSocket - https://github.com/robbiehanson/CocoaAsyncSocket). This method should work fine your your use case. Since you are doing turn-based data (and since all of that data is vital) I would not recommend using UDP sockets (but those would work if you were solely passing position, video, or audio data where a dropped packet might not matter).
I am working with an electronics appliance manufacturer to embed LAN based control systems into the products. The idea is to serve up a system configuration/control interface through a web browser so clients never need to install software. We can communicate with the appliance by sending and receiving serial data through the embedded module. Since the appliance can also be controlled from a front panel UI, it creates a challenge to keep a remote web interface in sync with very low latency. It seems like websockets or some sort of Push is what we need for handling real time events from the server to clients.
I am using a Lantronix Mathport AR embedded device server. Out of the box the unit will serve up any custom HTML and java servlets/applets. We have the option to install a lightweight Linux distro if we need more flexibility. I am not sure how to implement any server side apps since the device is not running standard Apache. I believe it is using Boa.
Can anyone guide me in the right direction of how to do this?
Some general info...The WebSocket protocol (draft spec here) is a simple layer on top of TCP. What this means is that, if you already have a TCP server for your platform, implementing the WebSocket is just a matter of hours. The protocol specifies a handshake and two ways of sending data frames.
I strongly suggest you start by reading the 39 pages spec.
As Tihauan already mentioned, start by reading the spec, and also note that there are still some changes ongoing, although websockets is now more stable than it was 1 year ago.
Key point for me was the requirement that websocket data is entirely UTF-8 text, which lends itself nicely to JSON based message definitions.
Our system uses a form of embedded linux, so we then added and made use of the following libraries:
"libwebsockets" from:
http://git.warmcat.com/cgi-bin/cgit/libwebsockets/
"jansson" from:
http://www.digip.org/jansson/
Using the above as support libraries, we created an internal lightweight "client/server" that allowed our other software modules to register for certain, applicable, websocket messages, and respond as needed. Worked great.
Good luck and best regards,
I'm a bit late, but Mozilla posted a guide entitled "Writing WebSocket servers", which literally guides you through writing a websocket server.
You will need to already know how HTTP works and have medium programming experience. Depending on language support, knowledge of TCP sockets may be required. The scope of this guide is to present the minimum knowledge you need to write a WebSocket server.
https://developer.mozilla.org/en-US/docs/Web/API/WebSockets_API/Writing_WebSocket_servers
OS : Linux.
I'm trying to find possible ways to implement web interface for my embedded system.
Currently there is a shell (text based) and a small set of commands are implemented to query the device.
I'm new to web development, my questions are:
What web server must I use? (I got apache up on my development setup and tried using CGI to fetch some pages, but seems like this not the right choice for embedded systems)
Assuming I'm using CGI, what strategy can be used for passing data between CGI and the Main App?
I intended to create a thread in the MainApp to handle the query from CGI script. This thread would call interfaces in the MainApp, retrive the data and pass it to CGI.
We use Lighttpd on our embedded systems, it's small and very easy to integrate. There are also specialized webservers with features especially geared to embedding, like AppWeb, which in my opinion is also a very nice product.
For the communication between the main application and the CGI's you can use sockets, or System V message queues if those are available on your embedded platform. The advantage of SYSV message queues is that they're very easy to use and manage, and messages in the queues survive restarts of the applications, but they also have some quirks (like you can't select() on them).
As web server another choice is thttpd. I use it successfully in an industrial product.
For the communication between CGI and main application sockets is the right choice.
There is no web server you must use, but there are some better choices for embedded than apache. Apache is designed for embedded and is bigger and slower.
I would not recommend CGI. It is slow to run and slow to develop. I can speak for Appweb for which I'm one of the developers. Appweb has two good web frameworks:
Ejscript which is a server-side Javascript framework for Appweb
ESP which is an MVC C-Language web farmework
ESP is extremely fast and provides easy binding of controllers to URLs. Ejscript is bigger and has a more extensive class library. Both are designed for embedded. Both are much better than CGI and execute 20+ times faster than CGI.
I am working in LuCI, which is a light CGI for embedded device. Actually it is for openwrt which is a open source project of wireless router.
The server is uhttpd , light and powerful.
The CGI script is Lua whose interpreter is no more than 10k, delicate, right? And it is developed by C and can communicate with C, powerful.
So this is my suggest.
We use JUCI with openwrt. It is written in javascript that runs on the client browser and communicates with web server over json rest api. The backend can be implemented in any language but we use reusable components written in C that plug into system bus (ubus). This means that relevant services expose their functionality through ubus which can both be used through cli and through rest api. It's actually pretty nice.