missing bytes... - Protocols

This is a discussion on missing bytes... - Protocols ; Hi everyone, After no luck with this issue, I thought of posting it here.. Heres what I am trying to do.. I am sending out commands out of a file through serial port to my application which returns me the ...

+ Reply to Thread
Results 1 to 6 of 6

Thread: missing bytes...

  1. missing bytes...

    Hi everyone,

    After no luck with this issue, I thought of posting it here.. Heres
    what I am trying to do..

    I am sending out commands out of a file through serial port to my
    application which returns me the response accordingly in return..


    ...
    ....
    transmit /binary /noecho /nowait
    input 1 -1
    ..output := \fhexify(\v(input))
    echo \m(output)
    ....
    fopen /write \%c
    ...
    fwrite /line \%c \m(output)
    ...
    fclose \%c



    The script works fine. The response as under is outputted to the
    'outputfile'. Now when I echo the response I get

    16 06 14 34 47 12 01 87
    instead of
    16 06 14 34 47 12 00 01 87 00 00 00

    Note the difference after the 6th byte. The 7th and 8th byte which is
    00 01 shows up as 01 and 10th, 11th and 12th bytes do now show up at
    all. However I have had success getting bytes in the order such as
    below and echoing this command works fine.
    16 06 14 34 46 11 00 00 BB 10 00 00

    If anyone has any idea of whats going on here then please help me.

    Thanx,

    Ray

  2. Re: missing bytes...

    In article ,
    icurmt wrote:
    : After no luck with this issue, I thought of posting it here.. Heres
    : what I am trying to do..
    :
    : I am sending out commands out of a file through serial port to my
    : application which returns me the response accordingly in return..
    :
    :
    : ..
    : ...
    : transmit /binary /noecho /nowait
    : input 1 -1
    : .output := \fhexify(\v(input))
    : echo \m(output)
    : ...
    : fopen /write \%c
    : ..
    : fwrite /line \%c \m(output)
    : ..
    : fclose \%c
    :
    :
    :
    : The script works fine. The response as under is outputted to the
    : 'outputfile'. Now when I echo the response I get
    :
    : 16 06 14 34 47 12 01 87
    : instead of
    : 16 06 14 34 47 12 00 01 87 00 00 00
    :
    : Note the difference after the 6th byte. The 7th and 8th byte which is
    : 00 01 shows up as 01 and 10th, 11th and 12th bytes do now show up at
    : all. However I have had success getting bytes in the order such as
    : below and echoing this command works fine.
    : 16 06 14 34 46 11 00 00 BB 10 00 00
    :
    C-Kermit and K95 written in C, in which strings are NUL-terminated.
    Thus it is virtually impossible for it to deal with strings that contain
    NUL characters -- we would not be able to use C library calls or Unix
    system services, all of which require strings to be in this format.

    This applies also the INPUT buffer. \v(input) is a string, hence by
    definition NUL-terminated. Realizing that it is common to receive NUL
    characters on a communication connection as padding and/or part of the
    Telnet NVT data stream, the INPUT command discards NULs so the \v(input)
    value will not be truncated the first time a NUL arrives.

    The only way to deal with NUL characters is on a per-character basis.
    If you want to read a series of characters from the connection that can
    include NULs, you have to do it using INPUT with no target text. Example:

    while (some condition) {
    input 1
    if fail (do something)
    fwrite /char \%c \v(inchar)
    }

    This works because when \v(inchar) is NUL, that's equivalent to FWRITE /CHAR
    having no text argument at all, in which case it writes a NUL character.

    - Frank

  3. Re: missing bytes...

    Looks like the INPUT (\v(input)) operations discard and ignore NUL
    characters that arrive from the communication device. Is there any way
    that can be turned on or use some other operation instead of INPUT.

    Ray

    icurmtdude@yahoo.com (icurmt) wrote in message news:...
    > Hi everyone,
    >
    > After no luck with this issue, I thought of posting it here.. Heres
    > what I am trying to do..
    >
    > I am sending out commands out of a file through serial port to my
    > application which returns me the response accordingly in return..
    >
    >
    > ..
    > ...
    > transmit /binary /noecho /nowait
    > input 1 -1
    > .output := \fhexify(\v(input))
    > echo \m(output)
    > ...
    > fopen /write \%c
    > ..
    > fwrite /line \%c \m(output)
    > ..
    > fclose \%c
    >
    >
    >
    > The script works fine. The response as under is outputted to the
    > 'outputfile'. Now when I echo the response I get
    >
    > 16 06 14 34 47 12 01 87
    > instead of
    > 16 06 14 34 47 12 00 01 87 00 00 00
    >
    > Note the difference after the 6th byte. The 7th and 8th byte which is
    > 00 01 shows up as 01 and 10th, 11th and 12th bytes do now show up at
    > all. However I have had success getting bytes in the order such as
    > below and echoing this command works fine.
    > 16 06 14 34 46 11 00 00 BB 10 00 00
    >
    > If anyone has any idea of whats going on here then please help me.
    >
    > Thanx,
    >
    > Ray


  4. Re: missing bytes...

    I tried it and it gave the same result as before. The NUL chars were
    ignored. However, something I dont understand here is that session log
    which is set as "set session-log binary" doesn't have the NUL
    character in it as well. Well, not sure, but possibly cause it logs
    the same (\v(input) buffer.



    fdc@sesame.cc.columbia.edu (Frank da Cruz) wrote in message news:...
    > In article ,
    > icurmt wrote:
    > : After no luck with this issue, I thought of posting it here.. Heres
    > : what I am trying to do..
    > :
    > : I am sending out commands out of a file through serial port to my
    > : application which returns me the response accordingly in return..
    > :
    > :
    > : ..
    > : ...
    > : transmit /binary /noecho /nowait
    > : input 1 -1
    > : .output := \fhexify(\v(input))
    > : echo \m(output)
    > : ...
    > : fopen /write \%c
    > : ..
    > : fwrite /line \%c \m(output)
    > : ..
    > : fclose \%c
    > :
    > :
    > :
    > : The script works fine. The response as under is outputted to the
    > : 'outputfile'. Now when I echo the response I get
    > :
    > : 16 06 14 34 47 12 01 87
    > : instead of
    > : 16 06 14 34 47 12 00 01 87 00 00 00
    > :
    > : Note the difference after the 6th byte. The 7th and 8th byte which is
    > : 00 01 shows up as 01 and 10th, 11th and 12th bytes do now show up at
    > : all. However I have had success getting bytes in the order such as
    > : below and echoing this command works fine.
    > : 16 06 14 34 46 11 00 00 BB 10 00 00
    > :
    > C-Kermit and K95 written in C, in which strings are NUL-terminated.
    > Thus it is virtually impossible for it to deal with strings that contain
    > NUL characters -- we would not be able to use C library calls or Unix
    > system services, all of which require strings to be in this format.
    >
    > This applies also the INPUT buffer. \v(input) is a string, hence by
    > definition NUL-terminated. Realizing that it is common to receive NUL
    > characters on a communication connection as padding and/or part of the
    > Telnet NVT data stream, the INPUT command discards NULs so the \v(input)
    > value will not be truncated the first time a NUL arrives.
    >
    > The only way to deal with NUL characters is on a per-character basis.
    > If you want to read a series of characters from the connection that can
    > include NULs, you have to do it using INPUT with no target text. Example:
    >
    > while (some condition) {
    > input 1
    > if fail (do something)
    > fwrite /char \%c \v(inchar)
    > }
    >
    > This works because when \v(inchar) is NUL, that's equivalent to FWRITE /CHAR
    > having no text argument at all, in which case it writes a NUL character.
    >
    > - Frank


  5. Re: missing bytes...

    In article ,
    icurmt wrote:
    : I tried it and it gave the same result as before. The NUL chars were
    : ignored.
    :
    How do you know it didn't work? What kind of connection is it? Where
    are the NUL characters coming from?

    When I do it here, it works:

    fopen /write \%c foo
    if fail stop
    while true {
    input 5
    if fail break
    fwrite /char \%c \v(inchar)
    }
    fclose \%c

    The "foo" file has NUL characters in it, just where they are supposed to
    be, none missing.

    : However, something I dont understand here is that session log
    : which is set as "set session-log binary" doesn't have the NUL
    : character in it as well. Well, not sure, but possibly cause it logs
    : the same (\v(input) buffer.
    :
    SET SESSION-LOG BINARY tells Kermit to record every incoming character,
    including NULs, and it does. The session log is separate from \v(input).
    Incoming characters go straight to a file, not to a C string, so NULs
    are not a problem. However, by default (i.e. when SESSION-LOG is set to
    TEXT), they are discarded, as are certain other control characters,
    depending on the text-file format of the computer where Kermit is running
    (so, for example, carriage returns are discarded by C-Kermit but not by
    K-95).

    - Frank

  6. Re: missing bytes...

    It worked fine. I guess made some mistake in haste.

    Thanks for all your help.


    fdc@sesame.cc.columbia.edu (Frank da Cruz) wrote in message news:...
    > In article ,
    > icurmt wrote:
    > : I tried it and it gave the same result as before. The NUL chars were
    > : ignored.
    > :
    > How do you know it didn't work? What kind of connection is it? Where
    > are the NUL characters coming from?
    >
    > When I do it here, it works:
    >
    > fopen /write \%c foo
    > if fail stop
    > while true {
    > input 5
    > if fail break
    > fwrite /char \%c \v(inchar)
    > }
    > fclose \%c
    >
    > The "foo" file has NUL characters in it, just where they are supposed to
    > be, none missing.
    >
    > : However, something I dont understand here is that session log
    > : which is set as "set session-log binary" doesn't have the NUL
    > : character in it as well. Well, not sure, but possibly cause it logs
    > : the same (\v(input) buffer.
    > :
    > SET SESSION-LOG BINARY tells Kermit to record every incoming character,
    > including NULs, and it does. The session log is separate from \v(input).
    > Incoming characters go straight to a file, not to a C string, so NULs
    > are not a problem. However, by default (i.e. when SESSION-LOG is set to
    > TEXT), they are discarded, as are certain other control characters,
    > depending on the text-file format of the computer where Kermit is running
    > (so, for example, carriage returns are discarded by C-Kermit but not by
    > K-95).
    >
    > - Frank