vovkos's dashboard

Hey Tony!
Thanks for registering!

First, regarding saving Log & Transmit options in nssn files -- that was actually our intent.
Fixed version (1.7.5a) should be available on the web by now.

Now, to your idea regarding colorizing data ranges in packet.
You are right once again, it is very important to provide some tools for analyzing user-defined protocols.
We were planning to implement this feature one way or another from the very beginning.

The problem with your approach is this.
Imagine, you want to analyze IP packet (let's say the frame of your protocol has similar structure)
You can colorize source and destination IPs, flags and other fields -- no problem, but to move on you have to check the Protocol field.
Based on this field, you have to fork and colorize it as ICMP, UDP, or TCP. Right?

Therefore, simple offset-based analyzing is not enough.
The approach we have in mind is to provide user with a script engine that will allow to specify exact algortihm for dissecting the packet.
BTW colorizing is just one option, user should also be able to generate descriptive headers (like the ones Ninja Network Sniffer plug-in creates for IP4/IP6/TCP/UDP) etc.

We are not promising that will be implemented in the nearest releases though. – vovkos, on December 16, 2008 03:06

Hey Tony!

I guess we got confused regarding this issue -- we thought you were talking about Plain Text Packet mode. In which case Ctrl+<letter> is a bit out-of-scope, and Ctrl+ENTER indeed adds CR+LF.
Until I realized after this post that the mode in question is in fact HEX-ASCII Packet!

And you are absolutely right!
HEX-ASCII of course should handle Ctrl+M properly by adding CR into the packet, not by sending the packet.

This will be fixed in the nearest realease.</letter> – vovkos, on December 12, 2008 02:33

Thanks :) – vovkos, on July 30, 2008 05:40

We also plan to include WinPCap into Ninja installer package for convenience.
But you are right, error message should not be there even if no wincpap is installed (for users that are not interested in network sniffing)
We will fix that in future revisions. – vovkos, on July 30, 2008 05:38

Let me add some clarification regarding this topic.

For the time being, we are not planning to charge for our TIDE software, even when we take it out of beta (which is to happen soon). We will do our best (but do not undertake) to keep this policy in the future. We can afford to do so because we also sell related hardware.
Ninja is a different story. It simply has no related hardware, and we at least need to cover the the process of turning a set of separated internal utilities into a finished product, right?

Now to rather confusing topic of relations between Ninja and existing packet sniffers.

Originally Ninja (which was not called Ninja at that time ;) was meant to be an advanced terminal emulation program with support of multiple transports (TCP/UDP/PIPE/Serial), client & server modes, UDP broadcasts and ability to handle binary data.
But the resulting modular and asynchronous I/O architecture and -- more importantly -- the beautiful logging engine were simply too good to stop just here :)
So we decided to add monitoring capabilities as well (serial sniffer is definitely coming in the future releases) -- to turn advanced terminal emulation program into a well-rounded communication debugging tool.

The difference between Ninja Network Sniffer plug-in and existing packet sniffers such as WireShark -- is in the representation of captured packets.
For example, WireShark simply cannot show the contents of 2 packets at once -- you have to switch from packet to packet to see the contents.
Our log engine lets us show all the packet contents side-by-side in a single view, making it much easier to follow the actual data flow.
Of course current protocol parsing capabilities of Ninja Network Sniffer plug-in could not match those of WireShark -- which has been in development for over a decade.
Currently we only have support for basic internet protocols such as TCP and UDP, but if there is demand from customers we will work to improve that.

BTW Ninja has another approach to sniffing TCP/UDP/PIPE connections, and that is Socket Proxy plug-in.
Being proxy, it redirects the connection between 2 endpoint and all the data they exchange -- logging it in the process.
That means you also get the contents of data flow, but this time you get it in an even clearer representation, avoiding "packet" notation.
Not to mention that regular network sniffers (WireShark included) simply do not fit into certain scenarios.

Wrapping up, Ninja is not trying to replicate functionality of WireShark and other packet sniffers.
Instead, it introduces a different approach to viewing captured data.
But even if you decide to stick with your favorite tried-and-true packet sniffer, other Ninja plug-ins still can offer functionality useful in the fight against issues in communication area.

sock.setdata takes a string as an argument.
therefore, limitation is the same as for any string -- 255.

but i agree that compiler should give a warning about trimming the literal (as well as trimming the length of string variable if requested length is too long, like dim s as string(512))

in cases like that always trust Source Browser more than helpfile.
Source Browser parses actual platform definition header files, so it is guaranteed to show most relevant declarations -- the ones that will be passed to compiler.

talking about "rtc" object, rts.set/rtc.get have been replaced with setdata/getdata at some moment -- and by the way it is also reflected in the latest helpfile (the one comes with the latest release of TIDE)

here is the reason for the above replacement.
with introduction of structures '.' char cannot be treated as part of identifier anymore. at the same time, "get" and "set" are reserved words used for declaration of properties. Therefore, all the object methods named "get" and "set" have been renamed.

Thanks for you opinion!!

I also don't like when programs generate traffic without giving me an option do anything about that.
But I believe if not done automatically, customers will hardly click the Check for updates menu item often enough (if ever)
So I guess compromise solution would be an option, like a checkbox "Check for updates automatically"

there is currently no way to drag data back from the system buffer to basic variables, setdata is kind of a one way ticket.
so if you want to have a complete serial dump of transmitted data, you have to manually duplicate each call to sock.setdata with a call to ser.setdata.

i understand that adding data to TX buffer could possibly happen in numerous places of your code, so i would approach this issue by defining two helper functions like

sub addtx(byref data as string)
sock.setdata(data)
#ifdef _SER_DUMP
ser.setdata(data)
#endif
end sub

sub tx
sock.send
#ifdef _SER_DUMP
ser.send
#endif
end sub

and then using those helpers instead of calling sock.setdata/sock.send directly, while you can define/undefine _SER_DUMP whenever serial dump is waned/unwanted

There is no public bugtrack facility on Tibbo website, sorry.

Yes, you can send more than 255 at once (up to socket TX buffer size).

Use a couple of sock.setdata to accumulate data in internal buffer, and then use sock.send to actually send all the buffered data at once

Let me add my 5 cents on some of the above topics

#1)
Good point! We will do it in the next release.

#2)
I personally *hate* basic syntax, but Erez gave a brief explanation above on why basic was chosen in the first place. However, we DO have plans on supporting other languages as well. In fact, TIDE architeture was redone not so long ago to support multiple syntax parsers in a source browser. And our application binary file format and program database file format are independent of the source language as well.
So to support a new language all we have to do is to write a new compiler and a syntax parser for source browser. However, that is a *huge* task -- and of low priority. So it's not likely to be done soon.

#4)
Good point!
I can't promise this will be implemented in the nearest release, but it's to be done for sure.

One question though -- would you prefer this feature to work silently (check for updates in the background and notify user if newer version is available) -- or require an explicit action from user (like clicking "Check for updates" menu item) before doing anything?

There is currently a bug in web-server implementation in firmware, which causes certain file extensions (like .swf, .js etc) to fail to transmit..
We are aware of it and it is likely to be fixed in our next release

#1)
you can transmit up to 255 characters with a a single call to setdata (since string size limit is 255). But you can keep calling setdata to accumulate a larger amount of data, up to socket tx buffer size (which can be set using sock.txbuffrq + sys.buffalloc)

#2)
no, you can't use setdata for that purpose since it's not a property.
but you can set up a single string buffer holding the data and then use it twice, once for socket and second time for serial.

Hey!

Currently string size limit is 255 bytes.
Which in fact is enough most of the time -- when string var is used to hold actual character string.
But of course it might come as a limitation when string var is used for holding a binary buffer..
We do plan either to extend string limit up to 65535 for EM1xxx or to introduce second string type, named something like "stringxl" or "buffer" in future versions of Taiko.
For now, however, it's 255.

By the way, latest versions of TIDE support string literal escape sequences, just like in C, so instead of

s = "A1234567890"
s = s + chr(13) + chr(10)

you can write

s = "A1234567890\r\n"

to get the same results