LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Slow TCP duplex handling on remote connections

I forgot to add the list of libraries from the system folder on the sbrio:

 

config.cdf

criosd.out

errlog.txt

ftpserve.out

libexpat.out

libiconv.out

lvalarms.out

lvanlys.out

lvblas.out

lvrt.out

nbfifo.out

niCPULib.out

NiFpga.out

niorba.ocm

niorbs.out

nipals.out

niriorpc.out

niriosrv.out

nirpcs.out

nisvcloc.out

NiViSrvr.out

NiViSv32.out

ni_emb.out

nvdata.bin

registry.out

rtvarsup.out

settime.out

target.out

tdms.out

tsengine.out

ts_dio.out

ts_rtc.out

ts_sntp.out

visa32.out

VisaCtrl.ocm

VisaCtrl.out

vxfpsup.out

vxWorks

vx_exec.out

mxs.mxr

mxsdd.out

TgrDD.out

NiEnAsrl.out

NiViAsrl.out

NiViEnet.out

NiViPxi.out

nivirio.out

NiViUsb.out

 

Anything here that could be related to networking? I'm having a look into some candidate files using a hex editor.. don't know if it will be of any help, though..

 

Roger

 

Message Edited by RogerI on 04-07-2010 04:04 PM
0 Kudos
Message 51 of 63
(1,422 Views)

I got someting in NiViEnet.out, could it be something like this?

 

hexeditor.jpg

 

Roger

 

0 Kudos
Message 52 of 63
(1,420 Views)

I'm 99% positive that the setsockopt function is actually in the vxWorks file (without any ending) but since it is the actual kernel it may be in a different binary format than the usual .out shared libraries and therefore the Call Library Node may not be able to link to it.

 

But all you would need to do is writing a small shared library module (.DLL on Windows, .so on Linux, .out on VxWorks. .Framework on Mac OS) that links this function and exports a somewhat different function name. (A different function name is very important since I learned the hard way that VxWorks has only one big global symbol table that any exported shared function is listed in and having a shared library export the same name as another already existing symbol makes that library simply fail to load.

 

You do not need the VxWorks Workbench or whatever it is called software. There is also a fully GNU based toolchain available. It is command line only while the VxWorks has a nice graphical user interface but it has worked for me in the past. NI has a distribution here to download. You just have to watch out that LabVIEW 8.2 uses a different VxWorks version than the newer LabVIEW versions and therefore needs also a different toolchain.

 

I'm currently working on a much more involved total replacement library for all LabVIEW network functions that would automatically support reading and setting the options and more on any connection, among other things such as IPv6, ICMP, raw sockets, and transparent SSL support. (I don't think IPv6 is supported on the RT targets though and getting SSL to work on there will also require some modifications to the SSL libraries too!) However I'm still quite a bit away from starting the work to compile and test that code for the real time targets so it won't be of much help for you right now.

Message Edited by rolfk on 04-08-2010 07:29 AM
Rolf Kalbermatter
My Blog
0 Kudos
Message 53 of 63
(1,411 Views)

RogerI wrote:

I got someting in NiViEnet.out, could it be something like this?

 

 

 

Roger

 


Hmm, NiViEnet is the TCP/IP passport for the VISA software and as such obviously would need to IMPORT socket functions. So I have a strong suspicion that this is actually the import symbols table and not the export symbols table.

Rolf Kalbermatter
My Blog
0 Kudos
Message 54 of 63
(1,410 Views)

Rolf,

 

Does your tcp code have a FOSS license? If that is the case, how do I get hold of it?

 

/Roger

 

0 Kudos
Message 55 of 63
(1,394 Views)

RogerI wrote:

Rolf,

 

Does your tcp code have a FOSS license? If that is the case, how do I get hold of it?

 

/Roger

 


Sorry I do not intend to make the shared library source code of that LabVIEW library available.

 

It does make use of a few undocumented features in LabVIEW, but more importantly this source code represents MANY hours of programming, testing and debugging, especially the last two parts are VERY time consuming.

Message Edited by rolfk on 04-08-2010 04:35 PM
Rolf Kalbermatter
My Blog
0 Kudos
Message 56 of 63
(1,387 Views)

Okay, I see. Too bad though, you might have got at least two more eyes looking for bugs and helping out with debugging. Smiley Indifferent

 

As Linus Torvalds put it: "With enough eyes on the code, even the hardest bugs becomes trivial".

 

Roger

 

Message 57 of 63
(1,380 Views)

RogerI wrote:

Okay, I see. Too bad though, you might have got at least two more eyes looking for bugs and helping out with debugging. Smiley Indifferent

 

As Linus Torvalds put it: "With enough eyes on the code, even the hardest bugs becomes trivial".

 

Roger

 


You may be right but my experience with publishing C source code for LabVIEW related tools is that nobody bothers to look at it when they get some problem. And those who might using it for whatever they decide (independant if it is compatible with the license the source code was brought out) do not seem to report back anything from their findings. I have in all those years never ever received any bug report for any of the LabVIEW related C code I have made available. I would like to think that this is because there have been no bugs in my C code, but I do know better than that. Smiley Wink

Rolf Kalbermatter
My Blog
0 Kudos
Message 58 of 63
(1,376 Views)

Rolf, I bet you are or have used some Linux distro, tell me, how much source code have you contributed back to eg. the kernel?

 

My high estimate is that for every 1000 Linux machines or users out there, there exist max 1 hacker that contribute code to any FOSS project.  

 

I solved my problem with a, "Cough", hax0r. Do a read after every write, and a write before every read. Too bad it creates extra IO and 1 byte extra traffic for every send and read.

 

Hack.jpg 

 

What code have you FOSS'd? 

 

Roger

 

0 Kudos
Message 59 of 63
(1,370 Views)

RogerI wrote:

 

What code have you FOSS'd? 

 

Roger

 


Well, quite a few libraries at OpenG are from my hand.

 

LabVIEW only:

- LabVIEW LargeFile library for Windows

- parts of the OpenG package manager which resulted later in the VIPM

- other contributions to OpenG

 

LabVIEW and C shared lib:

- LabVIEW ZIP library for Mac, Windows, Linux and LabVIEW RT

- LabVIEW Pipe library for Windows, Linux
- LabVIEW PortIO library for Windows

- LabPython library for Windows to integrate the Python interpreter into the LabVIEW script node, theoretically portable to Linux though never attempted it

 

Non-LabVIEW related:

 

- Some patches and fixes to the Wine project.

- A few minor patches to the ZIP library from Gilles Vollant based on zlib.

 

So while I certainly wouldn't count for making a significant difference in the FOSS world I do think I have done a little more than nothing. Smiley Very Happy

Rolf Kalbermatter
My Blog
Message 60 of 63
(1,350 Views)