Features

IPv6 is slowly but steadily taking over the Internet. IO Ninja is here to help testing IPv6-connectivity of your applications, drivers, devices.

No more question marks: IO Ninja can show and send characters in any Unicode encoding.

IO Ninja is powered by our innovative programming language Jancy which has a familiar C-family syntax and is tailor-made for IO and UI programming.

IO Ninja comes with an IDE that means it's not only possible to customize it -- it's fun (if you're a nerd, that is).

IO Ninja's advanced logging engine shows massive logs in a clean, easy-to-read way. It'll gracefully display informational text messages side by side with binary data blocks in either hex view or plain text representations.

IO Ninja supports ANSI & X-Term terminal emulation; switch between log view and terminal console any time you want.

IO Ninja provides a powerful and elegant way of redirecting data from any transport to any other transport with Session Linking. Think Unix pipes, but better.

Write protocol analyzers/controllers, testing applications, and other utilities to extend existing sessions.

IO Ninja has excellent support for binary data transmission. Prepare packets using a text editor or a hex editor, or define a packet template using the Jancy language and fill it up using a property grid.

Ready? Ninja comes with... TCP client, TCP server, TCP proxy, UDP socket, SSH client, serial port, serial monitor, network sniffer, named pipe server, generic file stream and X-Modem file transfer. Will not make you coffee, though.

IPv6 Support

IPv6 has had a slow start and could be negletected for quite a while. But the importance of IPv6 support in your applications, drivers and devices is and will be growing. Sooner or later the support for IPv6 will simply become an absolute must.

To test IPv6 connectivity of your products you gonna need IPv6-enabled terminals and sniffers, and IO Ninja is here to help. You can listen on and connect to IPv6 or IPv4 addresses in all socket-based plugins of IO Ninja:

  • TCP Connection
  • TCP Listener
  • TCP Proxy
  • SSH Channel
  • UDP Socket

Remote address bar in client plugins is smart enough to distinguish between IPv4, IPv6 and host name strings, so you don't have to explicitly configure socket to be IPv4 or IPv6. Just type or paste the address and hit ENTER.

Unicode Support

IO Ninja provides support for all Unicode-based encodings:

  • UTF-8
  • UTF-16
  • UTF-16 (big-endian)
  • UTF-32
  • UTF-32 (big-endian)

All IO Ninja components including log engine, terminal emulator, text transmit & binary transmit are all capable of dealing with UTF data. This means you are free to send and receive data in any of the above encodings.

Jancy Scripting

Jancy is a new language heavily influenced and inspired by both Java and C++. It takes the best from the two worlds and blends it together, adding its own share of innovative features. It's a next-generation scripting language perfectly suited for both IO and UI programming. One of the primary motivations for creating Jancy was IO Ninja.

ABI compatibility with C/C++

Jancy is ABI-compatible with C/C++ (ABI stands for application binary interface). This has two major benefits.

Firstly, it simplifies and at the same time increases effectiveness of the application-to-script interaction. There is no need to pack data into variant-like containers and push them on the VM stack before calling a user script function – instead, you call it just like you'd call any other function in your program: Jancy understands all major calling conventions.

Secondly, it allows copy-pasting C definitions of protocol headers. C is the de-facto standard language for system programming and it’s possible to find the C-definition of virtually any protocol in existence. Need to use this protocol from Jancy for analyzing/re-implementing/testing? Copy-paste the protocol header definition, and Jancy will most likely eat it. Even if not (of course, there are differences between C and Jancy syntax), the required changes should be minimal. This could be particularly useful considering another prominent feature of IO Ninja, the packet builder.

Pointers

Jancy provides a feature that few other languages have: safe data pointers. It gives you an opportunity to safely “walk” across the data buffers with pointer arithmetic, analyzing or building a packet.

io.IpHdr const* ipHdr = (io.IpHdr const*) (p + baseOffset);
switch (ipHdr.m_protocol)
{
case io.IpProtocol.Icmp:
    processIcmpHdr (p, baseOffset + sizeof (io.IpHdr));
    break;

case io.IpProtocol.Tcp:
    processTcpHdr (p, baseOffset + sizeof (io.IpHdr));
    break;

case io.IpProtocol.Udp:
    processUdpHdr (p, baseOffset + sizeof (io.IpHdr));
    break;
}

There is no better way to deal with binary data than pointers and pointer arithmetic. But even if there was, the argument from the previous section still holds: C is the standard of system programming, therefore, it’s easy to find C-definitions of protocol headers.

Another pointer-related feature of Jancy that comes in handy in multi-threaded IO programming is function pointers. Jancy function pointers support partial application and scheduling.

Partial application means that you can capture “context” arguments for your callback (event handler/completion routine/etc).

Scheduling means you can assign a user-defined “scheduler” which will ensure execution of your callback in the correct environment (in the specific worker thread, under the lock, as a Window Message handler and so on).

EventContext* context = new EventContext;
context.m_socket = socket;
context.m_requestId = requestId;

// capture context and schedule it to be run in worker thread

socket.m_onSocketEvent += onSocketEvent ~(context) @ m_workerThreadScheduler;

// ...

void m_onSocketEvent (
    EventContext* context,
    SocketEventParams const* params
    )
{
    // we are in worker thread, handle socket event
}

Properties

Properties is not unique feature of Jancy: other languages have them, too. But we are (almost) sure no other language have properties implemented as good as Jancy. Jancy provides all colors and flavor of properties you could imagine:

  • Indexed properties have syntax of arrays
  • Bindable properties notify subscribers when property has changed
  • Bindable data for auto-generating properties which do not need setters (and only needed for tracking changes)
  • Autoget properties can bypass the getter and access the “value” field directly
  • Simplified syntax form for declaring basic properties in the most natural way possible
  • Full syntax form for declaring properties of arbitrary complexity

Properties are generally useful, as they make code much cleaner and more natural-looking. But they come especially handy in UI programming.

opaque class ComboBox
{
    // ...

    bool autoget property m_isEditable;

    property m_editText
    {
        char const* autoget m_value;
        set (char const* value);
        alias bindable event m_onPropChanged () = m_onChanged;
    }

    char const* autoget property m_toolTipText;
    uint_t autoget property m_backgroundColor;

    char const* indexed property m_itemText (size_t index);

    property m_currentText
    {      
        char const* get ();
        alias bindable event m_onPropChanged () = m_onChanged;
    }

    event m_onChanged ();
    event m_onEnter ();

    // ...
}

Reactive Programming

Jancy is one of the few imperative languages with the support of reactive programming. When explaining what reactive programming is, the best example would be Microsoft Excel.

Everybody used Excel. Everybody knows when you write a “formula” in cell A and refer to other cells B and C, the dependencies are being built automatically. You change B or C, and A gets updated. You do not need to write event handlers that would be invoked when B or C changes, and in these handlers update all the dependent cells. Sounds ridiculous, right? Who would do that?

Well, that’s what UI programmers do. UI widgets provide events that fire when certain properties change, and if you need to track these changes and do something in response – you write an event handler, subscribe for the event, and update dependent controls/value from within that handler.

Jancy brings that Excel-like automatic execution of “formulas” when values referred from that formula change. How does Jancy know when to use Excel-like execution and when to use the traditional imperative approach? Reactors. You declare dedicated sections of reactive code, so-called reactors. Expressions within reactors behave like formulas in Excel and get automatically re-evaluated when bindable properties, referred from the given expression change. All the dependency building/subscribing/unsubscribing is happening automatically behind the scene.

reactor TcpConnectionSession.m_uiReactor ()
{
    m_title = $"TCP $(m_addressCombo.m_editText)";
    m_isTransmitEnabled = m_state == State.Connected;
    m_actionTable [ActionId.Disconnect].m_isEnabled = m_state != State.Closed;
    m_adapterProp.m_isEnabled = m_useLocalAddressProp.m_value;
    m_localPortProp.m_isEnabled = m_useLocalAddressProp.m_value;
}

construct ()
{
    // ...

    m_uiReactor.start ();
}

Of course, sometimes reactive approach doesn’t quite cut it, so you always have the traditional event handler approach at your disposal. Still, reactors might help here, too: Jancy provides a natural syntax of declaring in-reactor event handlers which will subscribe/unsubscribe automatically when reactor starts/stops.

int bindable m_state;
ComboBox* m_comboBox;

reactor m_reactor ()
{
    onevent (bindingof (m_state)) ()
    {
        // handle state change
    }

    onevent m_comboBox.m_onEnter ()
    {
        // handle enter hit in combobox
    }
}

More

Above we tried to outline the Jancy features that are especially important for IO Ninja: all of the mentioned features are heavily used there and you are more than welcome to explore the script sources and see for yourself how it makes code so much more natural and elegant.

But of course, that doesn’t wrap up the list of Jancy innovations. If you want to learn more, please visit Jancy website jancy.org

IDE

IO Ninja is scriptable and we do encourage our users to extend or modify it with custom Jancy scripts. However, coding in a non-cooperative environment, without code completion, member lists, argument tips et cetera is... not fun. Therefore, we provide an IDE tailored for building IO Ninja plugins.

IO Ninja IDE is based on NetBeans and comes in two flavors:

  • A customized NetBeans build
  • A separate NetBeans plugin

You can get the kind of your choice at download page

If you are an experienced NetBeans user, you would probably prefer the second one and add it to your NetBeans installation alongside other language plugins. If you are a first-time NetBeans user, we recommend you the first option which will set everything up in one go.

IO Ninja IDE provides everything you would expect from a modern IDE, including various code assisting features as well as wizards for creating Sessions and Layers:

Ninja Scroll Logging Engine

The logging engine was a strong selling point of IO Ninja since day one. To understand why it stands out, you have to think how most sniffers or monitors represent data.

Usually there is a "master list" of events, such as "incoming packet" or "error message", and then there is "details view". The user has to select the event in "master list" and then inspect event details in "details view".

The reason for this design of user interface is obvious: it's easy to implement. While this interface is acceptable, there are clearly situations when a single continuous log sheet (think of a huge HTML page) would be much easier to read.

So, why not use HTML? For a tiny log, that would have been fine. But unfortunately HTML is not suitable for displaying really huge pages, while logs of IO communications can grow to many gigabytes in size. So, we needed our own engine.

No other terminal emulator or packet analyzer can interleave binary data in text or hex-view forms with textual messages in potentially huge logs, providing a single, clean, searchable log sheet. IO Ninja could do it since the original release, and it got even better in version 3.

  • Interleaving binary and textual messages in a single continuous log sheet
  • Representing binary data in text or in hex-view form
  • Configurable merging (including setting a threshold for time difference)
  • Showing merged packet boundaries
  • Expanding/collapsing
  • Multiple modes for copying binary data
    • Hex
    • Text
    • Hex View
    • C Array
    • C Literal
    • Jancy Hex Literal
  • Saving a selected block of binary data to file
  • Displaying the offset and the selected range within a binary block

Terminal Emulator

IO Ninja features full ANSI and x-term terminal emulation. Each session which provides an RX data stream (not all sessions do! Think of packet-oriented sessions) has a secondary terminal view next to the log view, and the user is free to switch between the two depending on what works best in each particular case.

Session Linking

This feature turns IO Ninja into a universal proxy. You can redirect data from Serial into TCP, or from TCP to SSH, or write an incoming stream to a file and so on.

Just start two sessions (they can be of completely different nature), link them, and all the data received on one end will be transmitted to the other.

When two sessions are linked, the transmit pane is hidden: transmitted data is coming from the other side of the link (which is bidirectional). You still maintain the full control over the session state.

Layers

IO Ninja extends its plugin model with a new kind of plugin: the layer. This separates "heavy" and "light" plugins.

Creating a full-fledged session plugin involves quite some work. So, what if you just want to write a simple test application which would, let's say, wait for incoming commands over TCP connection and send something in return? We already have a TCP connection plugin, should we re-implement the whole thing? Besides, what if our simple test application also needs to run over Serial, not just TCP? Wouldn't it be better if we could write a simple piece of code which would "ride" the existing connection and just add-on desired features?

That's what IO Ninja layers are for. A layer is a module you attach on top of existing session (which provides basic transport functionality), and the layer extends it. A layer can:

  • Add extra UI to perform specific operations (XModem send/receive)
  • Listen for incoming log messages and do something in response
  • Use the underlying session for data transmission
  • Modify log representation (for example, do alternative processing for certain log records, and fall back to the previous representer for the rest of log records)
  • Convert the log: produce the secondary log with "decoded" messages, thus "analyzing" the application-level protocol.

This allows writing all kinds of protocol controllers/analyzers, testing programs and other useful utilities which are capable of working independently from the underlying transport.

Packet Builder

IO Ninja allows you to prepare packets for transmission in multiple ways.

You can enter just text into the IO Ninja text editor. In this mode IO Ninja supports insertion of special characters via escape sequences (\r \t \xff etc).

Binary packet transmission is where IO Ninja shines. It has a built-in hex-editor with insert/overwrite modes that lets you edit nibbles, highlights the selected octet, and shows the current offset and selected range.

Even more important, IO Ninja now comes with packet template editor, which allows describing the packet structure in Jancy language, and then edit its individual fields with a property grid!

Jancy is ABI-compatible with C, supports structure packing, bit fields and even integers with inversed byte order, aka bigendians! So you can describe any packet header, just like in C/C++, and even better!

Controllers

DS110x Family

Boards

EM1001