Hi there,

I know, there are other libraries for C# (and compatible VB.NET) around. Anyway, I started to work on my own library, just because I wanted to do it on my own to see where I get. I really want to make sure, that this library is not intended to criticise any of the existing ones!

Anyway, I think this library has some Pros (of course I do think, as it's mine ), while having other drawbacks.

Some Pros:
- Connecting to LFS is easy, just supply a string like "localhost:29999" and you're on your way
- You don't have to care about receiving messages, there is a clean event for any InSim message, no need to convert a byte-array to an object.
- To send a message, you just have to create an object and send it, no need to bother with getting it an byte-array or anything else.
- The "structs" (I chose to go for classes) don't know about there byte representation, therefore, it's easy to add new messages or change existing ones
- Although hurting .NET naming conventions, I chose to use class-names as defined in InSim.txt to ease finding, what you're looking for.
- The TestApplication is 90%-reflective, making it ready to go, if the library will be extended / updated.
- Trying to hide C++-specifics, whenever possible (e.g. you don't have to care about zero-ending strings or Numberplates with fixed char[8]).

Anyway, some Cons:
- It's not yet finished, missing a lot of "IS_Sendable"-Attributes [mostly(?) done in V1.0.0.1]
- No udpSocket implemented yet (although it should be quite easy)
- No support for OutGauge yet (missing the right idea for reacting to "no-header-packets" atm)
- Needs some refactoring (IS_Enums and IS_SubPackets both have bad, inconsistent names).
- The RequestManager was a bad idea, the packet themselves should know, how they can be requested.
- The ctor contains fixed size of the packets, will be replaced with dynamic calculation.


I'm posting that library in this early stage, because I will be on vacations next week and I fear that I won't like going on with this library immediatly after. On the other side, I think it would be to sad not to publish this library, as it might be useful for some coders to get some ideas.


I'm considering posting this lib at SourceForge to make it easier keeping up-to-date with it.
Sadly, I saw that there's nearly no traffic at JInSimLib, why is that? Is the audience for an InSimLib really that small?

This is my very first post of own code on the internet, so please be kind to me :-). But of course, I'd appreciate some honest statements about this library and the idea of making an SourceForge-Project.

Kind Regards
Jens Buchta (Red Runner)

Update 05.06.2007:
- Library updated to V1.0.0.1 (I accidently released the first version as 1.0.0.0 and don'T want to decrease the version number. This one is still not finished).
- All packets marked as "instruction" oder "both ways" in "ISP_enum" are now sendable
- Fixed a bug in IS_NLP - packet that caused application to crash
- Updated IS_NLP and IS_MCI to InSim of W32-Patch (variable size)
- Receive / Send - ComboBox in TestApp is now sorted
- minor bugfixes

Update 07.06.2007:
- Library updated to V1.0.0.2
- IS_NLP / IS_MCI contained wrong information, if received length < maximum length
- replaced Logging-Listviews with Treeviews in TestApp
- Added the abbility to see the contents of Sub-Packets (like NodeLap / Compcar) in TestApp - TreeViews

Known Issues
Library related:
- Library doesn't react to invalid packets properly
- Variable length packets always consume full length in memory

TestApp related:
- UI becomes unresponsive, if too many packets arrive (usually, if interval < 500ms and receiving IS_NLP / IS_MCI packets)
- TestApp doesn't handle any exceptions

Cool, good stuff! I had a quick look and it seems fine, although I've not tried to use it yet. I'll try and have a blast on it tomorrow, see if I have any problems or comments.

Hi, it seems really good. As i can see i am .NET beginner only Thanks for your code posted to this forum...

dude, stop reading my mind
i just needed this! thnx!

Quote from Red Runner :

Hi there,

Anyway, some Cons:
- No support for OutGauge yet (missing the right idea for reacting to "no-header-packets" atm)

I don´t know how your Sourcecode looks. But in my code just before the Select Case Part where I compare the PacketIDs I have a few Lines of code who measure the Packet Length and if the Packet has a Length of 92 I assume that it´s an Outgauge Packet.

Sadly in the Current LFS Version I use (W43) I can activate Outgauge, but LFS doesn´t send me the Packets... and I still don´t know why. But don´t mind... I hope above helps. And good Luck with your Project

I'm using your library in an InSim app that I'm working on at the moment. Overall it's very good work, and quite easy to use

The only problem that I am having at the moment is that it doesn't handle any socket exceptions. Is that by design? (i.e., should I handle the exceptions in my code?)

Also, is the Connected property a 100% foolproof way to test if the InSim socket is connected? I only ask because my application is multithreaded and I'm getting some funny results.

Thanks all for your comments, I appreciate that!

Regarding OutGauge:
I think I will implement "buedi"'s idea, thanks for that. To keep it simple (and safe), I think I will restrict the OutGauge incoming port to be different from the InSim incoming UDP-Port.
@buedi: Remember that OutGauge packets can be both 92 or 96 bytes. Have you tested used a tool like ethereal or Packetyzer to see, if LFS really doesn't send OutGauge-Packets?

Regarding Exception Handling:
To be honest, there's no concept at this stage. Just mentioned that the test app crashes, if it tries to connect to the wrong port.
But I think I won't catch the Socket-Exceptions, as I don't know, how I could react gently to them. All I can think of, is closing the connection and trying to re-establish it using the last connection details. Maybe this is a way, but later...
What I will do quite soon is implement a "UnknownPacketException" to react to packets with an unknown identifier. The "InvalidPacketLengthException" will be thrown, if the size of received message does not match the size expected from the header.

@Peptis: The Connected-property is, ähm, simply wrong. Just looked into the code and if the "clientSocket" isn't instanciated yet, it will throw an error. Stupid error...

Regarding Multithreading, it should work in a multithreaded environment, although I haven't tested it yet. But you should keep in mind that the underlying "socket" uses threading already, that's why I had to implement the "Thread safe UI-Updater".


As last node:
IS_NLP and IS_MCI still don't work properly and Version 1.0.0.1. I have (hopefully) fixed them in my version here, that I'll publish this evening.

Regards
Jens (Red Runner)

Thanks for your reply Jens. I'd like to re-iterate that I really like your library and I'm looking forward to further developments in it.

Hi, this library is absolutely helpful, thanks!

I noticed tho, that the IS_MCI's Position bytes are always 0, maybe that's not exactly news for you, but I hope you fix this in your next release.

Quote from Knu :

I noticed tho, that the IS_MCI's Position bytes are always 0, maybe that's not exactly news for you, but I hope you fix this in your next release.

Tried to reproduce that in V1.0.0.2 without success. I hope it is fixed now. If it isn't, feel free to debug through the code :-).
If the problem persists, please report, I'll take a look at it when I'm back from holidays.

I've identified an issue with the Connected property. It's not an error in your code, just something I thought I should point out for anyone else who is using this library.

The connected property behaves just like the Socket class' Connected property in that it tells you whether the socket was connected in the LAST operation; i.e., it does not tell you whether the socket is connected now.