tcp vi problems

[Michael Gaskin]

Greetings,

I am having some problems with an FTP client I wrote. The thing works
just fine when I run it in "debug" mode i.e. run it from the coding
windows. When I cut a binary and run it I get errors from the TCP Write
vi. Error #1 input parm in error (paraphrasing is mine). This problem
I believe is corrupting files.

The support folks suggested I use a different vi to open my files and
use the derived reference number instead of using a file path and the
read characters vi. Trouble is because it is an FTP implementation I
must carve up the file into lets 512 byte chunks. This means that I
need to know the offset of the file so that I can send the next bit of
data starting at the point where I left off. I can't find a vi that
will
allow me to do this and take the reference number.

I'm using LabView 5.1 on an NT box running NT 4. I have a 500M pentium
with 128 M of ram.

Is it possible that when I send binary files with the above vi (read
Characters) I am causing the problem?

Thanks
Mike

[Johnner]

Michael Gaskin wrote:

> I am having some problems with an FTP client I wrote. The thing works
> just fine when I run it in "debug" mode i.e. run it from the coding
> windows. When I cut a binary and run it I get errors from the TCP Write
> vi. Error #1 input parm in error (paraphrasing is mine). This problem
> I believe is corrupting files.

By "cut a binary," do you mean build an executable? It sounds to me as if
you might have some timing issues related to opening and closing connection
refnums. The only way I can envision getting an error 1 with TCP Write is
by feeding it an invalid refnum (i.e. connection closed or never opened in
the first place).

If I remember correctly, an FTP client requires two simultaneous TCP/IP
connections to the server. I don't know why you'd have to close one once it
was opened, but I also don't know how else you'd get error 1. You're
probably aware that the Internet Developers Toolkit from NI comes with an
FTP client, and I think there might some independently-written versions
lurking around out there somewhere. Then again, maybe you're doing this for
fun!

> must carve up the file into lets 512 byte chunks. This means that I
> need to know the offset of the file so that I can send the next bit of
> data starting at the point where I left off. I can't find a vi that
> will allow me to do this and take the reference number.

Is there a reason that good old "Read File" won't do this? It takes file
refnums and it's got a position offset input, as you require. This seems
like the best solution to me.

> Is it possible that when I send binary files with the above vi (read
> Characters) I am causing the problem?

The Read Characters VI should retrieve bytes regardless whether they're
printable ASCII or not. The more likely scenario is that the other side of
the FTP connection is misinterpreting your end-of-line characters or
something similar, depending whether it's the same OS or a different one
than the sender. I checked up on the RFC for the FTP protocol at one point,
and I remember that one of the tricks to achieve platform independency for
your client is to ensure that it formats the bytestream using a
platform-independent protocol. If your client doesn't specifically address
this issue, it's not going to be fully compliant to the RFC.

The bottom line is that an FTP client is not as trivial as it might seem to
create, and it may be worth the investment in the NI toolkit if you want a
nice robust solution. I suspect the phone/e-mail support guys at NI would
back me up on this one!

Regards,
John Lum
National Instruments

[Michael Gaskin]

John Lum wrote:

> Michael Gaskin wrote:
>
> > I am having some problems with an FTP client I wrote. The thing works
> > just fine when I run it in "debug" mode i.e. run it from the coding
> > windows. When I cut a binary and run it I get errors from the TCP Write
> > vi. Error #1 input parm in error (paraphrasing is mine). This problem
> > I believe is corrupting files.
>
> By "cut a binary," do you mean build an executable? It sounds to me as if
> you might have some timing issues related to opening and closing connection
> refnums. The only way I can envision getting an error 1 with TCP Write is
> by feeding it an invalid refnum (i.e. connection closed or never opened in
> the first place).
>

Yes I mean an executable.

>
> If I remember correctly, an FTP client requires two simultaneous TCP/IP
> connections to the server. I don't know why you'd have to close one once it
> was opened, but I also don't know how else you'd get error 1. You're
> probably aware that the Internet Developers Toolkit from NI comes with an
> FTP client, and I think there might some independently-written versions
> lurking around out there somewhere. Then again, maybe you're doing this for
> fun!
>

Fun and learning. Yes it requires a command channel and a data channel. The
command channel works fine and stays open all the time. The data channel is
open only during data transfers and I use the PASS command to determine the port
number for each transfer.

>
> > must carve up the file into lets 512 byte chunks. This means that I
> > need to know the offset of the file so that I can send the next bit of
> > data starting at the point where I left off. I can't find a vi that
> > will allow me to do this and take the reference number.
>
> Is there a reason that good old "Read File" won't do this? It takes file
> refnums and it's got a position offset input, as you require. This seems
> like the best solution to me.
>

The Read file will take the offset but it will then read to the end of the file
rather than stop at a specific spot i.e. 512 bytes.

>
> > Is it possible that when I send binary files with the above vi (read
> > Characters) I am causing the problem?
>
> The Read Characters VI should retrieve bytes regardless whether they're
> printable ASCII or not. The more likely scenario is that the other side of
> the FTP connection is misinterpreting your end-of-line characters or
> something similar, depending whether it's the same OS or a different one
> than the sender. I checked up on the RFC for the FTP protocol at one point,
> and I remember that one of the tricks to achieve platform independency for
> your client is to ensure that it formats the bytestream using a
> platform-independent protocol. If your client doesn't specifically address
> this issue, it's not going to be fully compliant to the RFC.
>
> The bottom line is that an FTP client is not as trivial as it might seem to
> create, and it may be worth the investment in the NI toolkit if you want a
> nice robust solution. I suspect the phone/e-mail support guys at NI would
> back me up on this one!
>

I'll re-read the spec to find out the platform independent stuff, I seem to
remember something about that in the spec.

>
> Regards,
> John Lum
> National Instruments

Thanks for the response.
Mike

[Johnner]

Michael Gaskin wrote:

> > Is there a reason that good old "Read File" won't do this? It takes file
> > refnums and it's got a position offset input, as you require. This seems
> > like the best solution to me.
> >
>
> The Read file will take the offset but it will then read to the end of the file
> rather than stop at a specific spot i.e. 512 bytes.

Aha--actually, Read File is a lot more flexible than that. If you supply an input
to "count" (e.g. 512) and wire a U8 to the "byte stream type" input, the VI will
produce a U8 array whose length is the count you specify. Drop in a "Byte Array to
String" node (the String >> Conversion subpalette), and you've got your 512
byte-long string with whatever offset you want.

Have fun!

--John

[lmc_rick@my-deja.com]

> I am having some problems with an FTP client I wrote. The thing works
> just fine when I run it in "debug" mode i.e. run it from the coding
> windows. When I cut a binary and run it I get errors from the TCP
Write
> vi. Error #1 input parm in error (paraphrasing is mine). This
problem
> I believe is corrupting files.
>

Mike;
You are now going thru what I went thru about 1 month ago.
but my application was just a standard TCP/IP Server Client
Interface, whereas you are performing an FTP implementation.
And while I was never able to determine the reasoning behind
the error, I was able to eliminate the error by putting a
100 to 200ms wait (experiment) in between the Write and Read
Functions. I did use a probe to determine that all of the
inputs were valid a
t the time of the Read, (Which is when I
was getting the error #1) however, I think that in the 'debug'
mode as you called it and when using a probe as I mentioned,
there is a slight timing difference. (perhaps not 100 ms but
still a difference.)

I hope this helps.
Rick


Sent via Deja.com http://www.deja.com/
Before you buy.

[Michael Gaskin]

Thanks for the suggestion I'm going to try it. When you say between the
read and write functions I assume you mean between the "read characters
from file" vi and the "TCP/IP Write" vi. In my implementation I connect
the output of the read characters directly to the input of the TCP write
function. I'm going to put a sequence box in with a timer set at?????

Regards
Mike

lmc_rick@my-deja.com wrote:

> > I am having some problems with an FTP client I wrote. The thing works
> > just fine when I run it in "debug" mode i.e. run it from the coding
> > windows. When I cut a binary and run it I get errors from the TCP
> Write
> > vi. Error #1 input parm in error (paraphrasing is mine). This
> problem
> > I believe is corrupting files.
> >
>
> Mike;
> You are
now going thru what I went thru about 1 month ago.
> but my application was just a standard TCP/IP Server Client
> Interface, whereas you are performing an FTP implementation.
> And while I was never able to determine the reasoning behind
> the error, I was able to eliminate the error by putting a
> 100 to 200ms wait (experiment) in between the Write and Read
> Functions. I did use a probe to determine that all of the
> inputs were valid at the time of the Read, (Which is when I
> was getting the error #1) however, I think that in the 'debug'
> mode as you called it and when using a probe as I mentioned,
> there is a slight timing difference. (perhaps not 100 ms but
> still a difference.)
>
> I hope this helps.
> Rick
>
> Sent via Deja.com http://www.deja.com/
> Before you buy.

[Johnner]

I'd urge you to continue debugging instead of going down a path that involves
dropping delays into the diagram until the program seems to work. The
problem with that is that you end up leaving little time bombs in the code
that surface when you build an executable, or deploy the VI on a target
machine, or buy a faster computer, or upgrade your OS.

There's nothing non-deterministic about a TCP/IP client/server application,
so LabVIEW must be generating these errors in response to specific parts of
your code. I'd suggest taking a closer look at the flow control you've
implemented between client and server. Make sure that each side is ready to
read when the other side writes, and knows how much is coming. Careful
debugging and examination of the client/server protocol that you have defined
should reveal a fixable problem.

--John

Michael Gaskin wrote:

> Thanks for the suggestion I'm going to try it. When you say between the
> read and write functions I assume you mean between the "read characters
> from file" vi and the "TCP/IP Write" vi. In my implementation I connect
> the output of the read characters directly to the input of the TCP write
> function. I'm going to put a sequence box in with a timer set at?????
>
> Regards
> Mike
>
> lmc_rick@my-deja.com wrote:
>
> > > I am having some problems with an FTP client I wrote. The thing works
> > > just fine when I run it in "debug" mode i.e. run it from the coding
> > > windows. When I cut a binary and run it I get errors from the TCP
> > Write
> > > vi. Error #1 input parm in error (paraphrasing is mine). This
> > problem
> > > I believe is corrupting files.
> > >
> >
> > Mike;
> > You are now going thru what I went thru about 1 month ago.
> > but my application was just a standard TCP/IP Server Client
> > Interface, whereas you are performing an FTP implementation.
> > And while I was never able to determine the reasoning behind
> > the error, I was able to eliminate the error by putting a
> > 100 to 200ms wait (experiment) in between the Write and Read
> > Functions. I did use a probe to determine that all of the
> > inputs were valid at the time of the Read, (Which is when I
> > was getting the error #1) however, I think that in the 'debug'
> > mode as you called it and when using a probe as I mentioned,
> > there is a slight timing difference. (perhaps not 100 ms but
> > still a difference.)
> >
> > I hope this helps.
> > Rick
> >
> > Sent via Deja.com http://www.deja.com/
> > Before you buy.