endian of within a tcp/ip byte tramission - TCP-IP

This is a discussion on endian of within a tcp/ip byte tramission - TCP-IP ; Dear group members, Sorry if my topic does not belong to this group. The topic is about endian of within a tcp/ip byte tramission. is the following sequence correct to send value 0x01 in tcp/ip serially: time 0: send 1 ...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 37

Thread: endian of within a tcp/ip byte tramission

  1. endian of within a tcp/ip byte tramission

    Dear group members,

    Sorry if my topic does not belong to this group.
    The topic is about endian of within a tcp/ip byte tramission.
    is the following sequence correct to send value 0x01 in tcp/ip
    serially:
    time 0: send 1
    time 1: send 0
    ..
    ..
    ..
    time 7: send 0

    Thank you

    --
    chong


  2. Re: endian of within a tcp/ip byte tramission

    In article <1157210457.194380.230870@m79g2000cwm.googlegroups. com>,
    wrote:
    >Sorry if my topic does not belong to this group.
    >The topic is about endian of within a tcp/ip byte tramission.
    >is the following sequence correct to send value 0x01 in tcp/ip
    >serially:
    >time 0: send 1
    >time 1: send 0
    >.
    >.
    >.
    >time 7: send 0


    No, tcp/ip does not specify the byte transmission order, and it
    is allowed (and happens in practice) that bits or bytes can be
    transmitted in parallel.

    Reversed bit ordering within octets is a property of -some- layer 2
    standards such as 10BaseT. By the time you get to 1000BaseT the
    bits are transmitted in clusters and so the timing diagram above does
    not hold (but when the bits were re-serialized, it would still logically
    be the LSB [Least Significant Bit] first for at least a part of a layer.)

  3. Re: endian of within a tcp/ip byte tramission

    ws.chong@ieee.org wrote:
    > Dear group members,
    >
    > Sorry if my topic does not belong to this group.
    > The topic is about endian of within a tcp/ip byte tramission.
    > is the following sequence correct to send value 0x01 in tcp/ip
    > serially:
    > time 0: send 1
    > time 1: send 0
    > .
    > .
    > .
    > time 7: send 0


    0x01 is presumably an 8-bit byte with the least significant bit set to
    1, all the rest set to 0. Since we're talking about just one byte, the
    byte order is trivial. You're just sending one.

    The bit order of transmission depends on the link layer. If you're
    sending this IP packet over Ethernet, then the least significant bit of
    each byte is sent first. So your description is correct for IP over
    Ethernet. Over other link layers, e.g. token ring or FDDI, it's the
    other way around.

    Bert


  4. Re: endian of within a tcp/ip byte tramission

    In article <1157229377.375484.121050@e3g2000cwe.googlegroups.c om>,
    Albert Manfredi wrote:

    >The bit order of transmission depends on the link layer. If you're
    >sending this IP packet over Ethernet, then the least significant bit of
    >each byte is sent first. So your description is correct for IP over
    >Ethernet. Over other link layers, e.g. token ring or FDDI, it's the
    >other way around.


    Not quite.

    1000BaseTX has multiple carrier frequencies, phase encoding,
    and constellation clusters. Makes it a bit difficult to say
    which bit was "sent first", since the encoding is *not* just
    straight binary.

  5. Re: endian of within a tcp/ip byte tramission

    Walter Roberson wrote:

    > No, tcp/ip does not specify the byte transmission order, and it
    > is allowed (and happens in practice) that bits or bytes can be
    > transmitted in parallel.


    RFC 791 (the IPv4 standard) Appendix B says:

    "The order of transmission of the header and data described in this
    document is resolved to the octet level. Whenever a diagram shows a
    group of octets, the order of transmission of those octets is the
    normal
    order in which they are read in English. ...

    "Similarly, whenever a multi-octet field represents a numeric quantity
    the left most bit of the whole field is the most significant bit. When
    a multi-octet quantity is transmitted the most significant octet is
    transmitted first."

    So the byte (octet) order is specified, but the bit order depends on
    the L2 specifics.

    > Reversed bit ordering within octets is a property of -some- layer 2
    > standards such as 10BaseT. By the time you get to 1000BaseT the
    > bits are transmitted in clusters and so the timing diagram above does
    > not hold (but when the bits were re-serialized, it would still logically
    > be the LSB [Least Significant Bit] first for at least a part of a layer.)


    I can agree with this. The GMII is a parallel 8-bit transfer, and some
    of the PMDs are 4 lanes wide (copper and fiber), but ultimately the
    Reconciliation Sublayer (Clause 35 of IEEE 802.3-2005) creates a serial
    8-bit sequence where the LSbit is sent first. Like other Ethernets.

    Bert


  6. Re: endian of within a tcp/ip byte tramission


    ws.chong@ieee.org wrote:

    > Sorry if my topic does not belong to this group.
    > The topic is about endian of within a tcp/ip byte tramission.
    > is the following sequence correct to send value 0x01 in tcp/ip
    > serially:
    > time 0: send 1
    > time 1: send 0
    > .
    > .
    > .
    > time 7: send 0


    Because TCP is specified at the byte level, it has no endianness rules.
    If you want to send an '0x01' as a one byte followed by a zero byte,
    you can do that. If you want to send it some other way, you can do that
    too. All that matters is that both ends agree. But that's not TCP's
    job.

    DS


  7. Re: endian of within a tcp/ip byte tramission

    In article <1157249586.898976.284860@e3g2000cwe.googlegroups.c om>,
    "David Schwartz" wrote:

    > ws.chong@ieee.org wrote:
    >
    > > Sorry if my topic does not belong to this group.
    > > The topic is about endian of within a tcp/ip byte tramission.
    > > is the following sequence correct to send value 0x01 in tcp/ip
    > > serially:
    > > time 0: send 1
    > > time 1: send 0
    > > .
    > > .
    > > .
    > > time 7: send 0

    >
    > Because TCP is specified at the byte level, it has no endianness rules.
    > If you want to send an '0x01' as a one byte followed by a zero byte,
    > you can do that. If you want to send it some other way, you can do that
    > too. All that matters is that both ends agree. But that's not TCP's
    > job.


    Except that everyone has to agree on how the bytes in the headers are
    sent.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

  8. Re: endian of within a tcp/ip byte tramission


    Barry Margolin wrote:

    > In article <1157249586.898976.284860@e3g2000cwe.googlegroups.c om>,
    > "David Schwartz" wrote:


    > > > time 0: send 1
    > > > time 1: send 0


    > > Because TCP is specified at the byte level, it has no endianness rules.
    > > If you want to send an '0x01' as a one byte followed by a zero byte,
    > > you can do that. If you want to send it some other way, you can do that
    > > too. All that matters is that both ends agree. But that's not TCP's
    > > job.


    > Except that everyone has to agree on how the bytes in the headers are
    > sent.


    Since he's talking about data being sent at different times, I think
    it's reasonable to assume that he's talking about application-level
    data, not headers. But you never know.

    A good analogy is asking what language you need to write a letter in to
    send it using the postal service. They don't care, so long as they can
    understand the address on the envelope. Of course, if the recipient
    does not speak the language the letter is in, it will not do them any
    good when they receive it.

    DS


  9. Re: endian of within a tcp/ip byte tramission

    David Schwartz wrote:

    > Since he's talking about data being sent at different times, I think
    > it's reasonable to assume that he's talking about application-level
    > data, not headers. But you never know.
    >
    > A good analogy is asking what language you need to write a letter in to
    > send it using the postal service. They don't care, so long as they can
    > understand the address on the envelope. Of course, if the recipient
    > does not speak the language the letter is in, it will not do them any
    > good when they receive it.


    The problem is, the IP standard does establish a byte transmission
    order for both the IP headers and the IP payload, giving specifically
    as an example the transmission of a multi-byte numerical value. And
    TCP, including its headers and its data payload, are included as IP's
    payload, as far as RFC 791 is concerned.

    Not to say that two specific hosts can't violate the standard. The
    point of the IP suite of protocols was and is to enable comms among
    multiple disparate "networks," without having to re-establish all these
    gory details every single time. It's not just the outer envelope the IP
    suite worries about.

    Bert


  10. Re: endian of within a tcp/ip byte tramission

    In article <1157309145.889005.233880@i3g2000cwc.googlegroups.c om>,
    Albert Manfredi wrote:

    >The problem is, the IP standard does establish a byte transmission
    >order for both the IP headers and the IP payload, giving specifically
    >as an example the transmission of a multi-byte numerical value. And
    >TCP, including its headers and its data payload, are included as IP's
    >payload, as far as RFC 791 is concerned.
    >
    >Not to say that two specific hosts can't violate the standard. The
    >point of the IP suite of protocols was and is to enable comms among
    >multiple disparate "networks," without having to re-establish all these
    >gory details every single time. It's not just the outer envelope the IP
    >suite worries about.


    That extends the byte order restrictions or standards too far. Appendix B
    of RFC 791 only talks numbers defined in the DDN TCP/IP Protocol Suite.
    Yes, the TCP header that is part of the IP payload must use network or
    big-endian byte order, but the following bits in the IP payload are
    just an ordered set of octets unless defined by some other standard.
    The Apollo/HP/Microsoft receiver-makes-it-right (or in Greg Chesson's
    paraphrase, receiver-makes-it-wrong) RPC standard is not violating any
    standard when it uses little-endian byte ordering. Yes, even Microsoft
    supports the htonl() functions and I'd raise my eyebrows at new arguments
    that htonl() is slow, but the choosing byte order of numeric fields
    in a new protocol is the most trivial of issues. Let's not elevate
    common, easy ntohl() practice into dogma or dogma into liturgy, because
    that gives aid and comfort to the priests of the Church of the ASN.1,
    or even worse, the evil notion that ASCII digit strings as in HTML is
    the divinely ordained solution for everything.


    Vernon Schryver vjs@rhyolite.com

  11. Re: endian of within a tcp/ip byte tramission

    Vernon Schryver wrote:

    > That extends the byte order restrictions or standards too far. Appendix B
    > of RFC 791 only talks numbers defined in the DDN TCP/IP Protocol Suite.


    I know you don't like the OSI 7-layer model, but this is another
    example where it comes in helpful -- in a perverse sort of way.

    Back in 1980/81, when RFC 791 was written, the writers were thinking in
    terms of the Transport Layer feeding directly the Application Layer. So
    it can easily be argued that what went for the IP and TCP (or UDP)
    layers is what fed the application. They seem not to have considered
    some other layer at which the byte order might have been reversed, at
    not until *after* the application receives the byte stream

    When the Presentation Layer came to be a couple or three years later,
    Layer 6, you could argue that this is where the big endian requirement
    of RFC 791 can be stopped.

    > Yes, the TCP header that is part of the IP payload must use network or
    > big-endian byte order, but the following bits in the IP payload are
    > just an ordered set of octets unless defined by some other standard.


    You can infer that if you like, but it's not implied by RFC 791.

    > Let's not elevate
    > common, easy ntohl() practice into dogma or dogma into liturgy, because
    > that gives aid and comfort to the priests of the Church of the ASN.1,
    > or even worse, the evil notion that ASCII digit strings as in HTML is
    > the divinely ordained solution for everything.


    It would have been extremely easy for RFC 791 or RFC 793 to clarify
    that the the actual payload bytes of the Transport Protocol were not
    covered by the ordering requirements of RFC 791 Appendix B. The simple
    fact is, no such simple statement exists. So, in the interest of
    interoperability and in the interests of preventing pointless and
    endless debates when writing requirements for applications that must
    run over the IP suite, my recommendation to spec writers is and
    continues to be to stick with big endian byte order.

    I don't like dogma either. But there's no reason to create confusion
    when what amounts to arbitrary details HAVE been decided already. As
    people seem to like to do many times.

    Bert


  12. Re: endian of within a tcp/ip byte tramission

    In article <1157316641.635978.227790@p79g2000cwp.googlegroups. com>,
    Albert Manfredi wrote:

    >> Yes, the TCP header that is part of the IP payload must use network or
    >> big-endian byte order, but the following bits in the IP payload are
    >> just an ordered set of octets unless defined by some other standard.

    >
    >You can infer that if you like, but it's not implied by RFC 791.


    On the contrary, that is the substance of the first sentence of Appedix B.
    The "multi-octet fields" mentioned after Fig. 11 are not every field
    in every upper layer protocol but only the fields standardized in RFC 791.


    >> Let's not elevate
    >> common, easy ntohl() practice into dogma or dogma into liturgy, because
    >> that gives aid and comfort to the priests of the Church of the ASN.1,
    >> or even worse, the evil notion that ASCII digit strings as in HTML is
    >> the divinely ordained solution for everything.

    >
    >It would have been extremely easy for RFC 791 or RFC 793 to clarify
    >that the the actual payload bytes of the Transport Protocol were not
    >covered by the ordering requirements of RFC 791 Appendix B. The simple
    >fact is, no such simple statement exists. So, in the interest of


    Nonsense. RFCs don't cover all cases not explicitly exempted. If the
    authors of RFC 791 had intended to say that all numbers anywhere "MUST"
    be big-endian, they'd have said that. Instead Appendix B clearly talks
    only about what it talks about. That's a Good Thing(tm), because
    otherwise the DDN Handbook would have mandated what would now be seen
    as the wrong characters, floating point numbers, and so on.


    > So, in the interest of
    >interoperability and in the interests of preventing pointless and
    >endless debates when writing requirements for applications that must
    >run over the IP suite, my recommendation to spec writers is and
    >continues to be to stick with big endian byte order.


    I emphatically agree with that statement, but it is quite different
    from the claim that RFC 791 mandates network byte order everywhere
    in IP payloads. The original claim that little endian numbers
    violate the IP standard would make everyone who uses FTP to transfer
    an 80*86 or VAX a.out into a scofflaw or heretic.


    >I don't like dogma either. But there's no reason to create confusion
    >when what amounts to arbitrary details HAVE been decided already. As
    >people seem to like to do many times.


    I see as much confusion created by efforts to twist RFCs into all
    encompassing holy writ as by ignoring them. Only someone who shouldn't
    be allowed to design a protocol would pick little endian numbers without
    very strong reasons after learning that the TCP/IP suite uses big endian.
    Mixing byte orders invites bugs and is just plain ugly. If saying
    "TCP/IP network byte order is big endian" doesn't answer the question,
    one should probably just walk away. On the other hand, people who treat
    RFCs as holy scripture that answers every question by mandating or
    prohibiting everything also shouldn't be allowed to design anything or
    even comment on designs.


    Vernon Schryver vjs@rhyolite.com

  13. Re: endian of within a tcp/ip byte tramission


    Albert Manfredi wrote:

    > The problem is, the IP standard does establish a byte transmission
    > order for both the IP headers and the IP payload, giving specifically
    > as an example the transmission of a multi-byte numerical value. And
    > TCP, including its headers and its data payload, are included as IP's
    > payload, as far as RFC 791 is concerned.


    Nonsense. That would be an atrocious layering violation.

    > Not to say that two specific hosts can't violate the standard. The
    > point of the IP suite of protocols was and is to enable comms among
    > multiple disparate "networks," without having to re-establish all these
    > gory details every single time. It's not just the outer envelope the IP
    > suite worries about.


    So if I'm using TCP to transport an executable between two windows
    machines using, say, FTP, I'm supposed to find every multi-byte
    constant inside the program and convert it into network byte order just
    to make the recipient do the same thing?

    That's absurd.

    DS


  14. Re: endian of within a tcp/ip byte tramission

    "David Schwartz" wrote:

    > Albert Manfredi wrote:
    >
    >> The problem is, the IP standard does establish a byte transmission
    >> order for both the IP headers and the IP payload, giving specifically
    >> as an example the transmission of a multi-byte numerical value. And
    >> TCP, including its headers and its data payload, are included as IP's
    >> payload, as far as RFC 791 is concerned.

    >
    > Nonsense. That would be an atrocious layering violation.


    A read of RFC 791 doesn't leave too much doubt.

    > So if I'm using TCP to transport an executable between two windows
    > machines using, say, FTP, I'm supposed to find every multi-byte
    > constant inside the program and convert it into network byte order
    > just
    > to make the recipient do the same thing?


    You have a point concerning the content of the executable file file
    being transported, and that's clearly stated in RFC 959 (see 3.1). But
    there's no question at all that FTP is specified to be big endian byte
    order, when it comes to its own headers, command, and reply fields,
    which are at Layer 7. And that the same holds true for all other IP
    applications.

    Bert


  15. Re: endian of within a tcp/ip byte tramission


    Albert Manfredi wrote:

    > "David Schwartz" wrote:


    > > So if I'm using TCP to transport an executable between two windows
    > > machines using, say, FTP, I'm supposed to find every multi-byte
    > > constant inside the program and convert it into network byte order
    > > just
    > > to make the recipient do the same thing?


    > You have a point concerning the content of the executable file file
    > being transported, and that's clearly stated in RFC 959 (see 3.1).


    You'll notice that that's all about converting the data into a format
    that's convenient for the end hosts and says nothing about network byte
    order or any standard beyond that. (Except NVT-ASCII, which is nothing
    like network byte order.)

    > But
    > there's no question at all that FTP is specified to be big endian byte
    > order, when it comes to its own headers, command, and reply fields,
    > which are at Layer 7. And that the same holds true for all other IP
    > applications.


    If you were right, FTP wouldn't have a choice.

    In any event, even if you're right, you're wrong. The layer on top of
    TCP can specify, for example, that a 16-bit number as two 8-bit
    unsigned integers in little-endian byte order. This would then mean
    that TCP had two 8-bit unsigned integers to send, not a 16-bit integer.
    So even if TCP had special rules for 16-bit integers, that would only
    apply if the level above it specified that it was passing TCP a 16-bit
    integer.

    If you claim the layer above TCP cannot do this, you get to immediate
    absurdities. For example, any protocol that sent numbers as ASCII
    digits would be violating the TCP protocol.

    DS


  16. Re: endian of within a tcp/ip byte tramission

    "David Schwartz" wrote:

    > If you claim the layer above TCP cannot do this, you get to immediate
    > absurdities. For example, any protocol that sent numbers as ASCII
    > digits would be violating the TCP protocol.


    I claim that when RFCs 791 and 793 were written, the "layer above TCP"
    *was* the application layer (now called L7). So if RFC 959 shows big
    endian byte order, as it does, then there wasn't any "layer above" that
    would have been doing the byte swapping. With the stipulations in 3.1,
    as I mentioned.

    FTP is one example, but the same holds for any number of other
    applications (SMTP, HTTP, DHCP, NTP, etc.). Look at the defined fields
    in all of these and show me where byte order is not big endian.

    How does this apply to ASCII? If an ASCII number is represented, big
    endian byte order simply means that the ASCII representation is
    transmitted in the same order as when written on a page, left to right.
    When ASCII is used, this is the general rule.

    What's truly absurd is to insist that big endian byte order is not used
    throughout the IP protocol family, up and down the protocol stack.

    Bert


  17. Re: endian of within a tcp/ip byte tramission


    Albert Manfredi wrote:

    > "David Schwartz" wrote:


    > > If you claim the layer above TCP cannot do this, you get to immediate
    > > absurdities. For example, any protocol that sent numbers as ASCII
    > > digits would be violating the TCP protocol.


    > I claim that when RFCs 791 and 793 were written, the "layer above TCP"
    > *was* the application layer (now called L7). So if RFC 959 shows big
    > endian byte order, as it does, then there wasn't any "layer above" that
    > would have been doing the byte swapping. With the stipulations in 3.1,
    > as I mentioned.


    The application itself can, and usually will, have multiple layers. For
    example, SNMP over UDP contains an intermediate BER layer between SNMP
    and UDP.

    > FTP is one example, but the same holds for any number of other
    > applications (SMTP, HTTP, DHCP, NTP, etc.). Look at the defined fields
    > in all of these and show me where byte order is not big endian.


    We aren't talking about TCP, not SMTP, HTTP, DHCP, or NTP. That many
    people using TCP have chosen to use big-endian byte order does not mean
    that it is a TCP requirement. SMTP, for example, sends numbers in
    ASCII.

    > How does this apply to ASCII? If an ASCII number is represented, big
    > endian byte order simply means that the ASCII representation is
    > transmitted in the same order as when written on a page, left to right.
    > When ASCII is used, this is the general rule.


    In other words, there is no rule that numbers that exceed one byte are
    sent in big-endian order. Some protocols send them that way, some send
    them other ways.

    > What's truly absurd is to insist that big endian byte order is not used
    > throughout the IP protocol family, up and down the protocol stack.


    You didn't say it was used, you said it was a standard for the TCP
    payload that is established by the TCP specification. If that were
    true, why wouldn't SMTP use it? (Answer: Because they choose ASCII
    which works better for them, and that is their right.)

    In any event, how could the RFC specify a particular byte order for the
    payload without specifying where the numbers begin and end? You would
    still need another protocol layered on top of TCP to say that, yes,
    that is a 4-byte integer, or that's a 2-byte integer.

    DS


  18. Re: endian of within a tcp/ip byte tramission

    "David Schwartz" wrote:

    > Albert Manfredi wrote:


    >> FTP is one example, but the same holds for any number of other
    >> applications (SMTP, HTTP, DHCP, NTP, etc.). Look at the defined
    >> fields
    >> in all of these and show me where byte order is not big endian.

    >
    > We aren't talking about TCP, not SMTP, HTTP, DHCP, or NTP. That many
    > people using TCP have chosen to use big-endian byte order does not
    > mean
    > that it is a TCP requirement. SMTP, for example, sends numbers in
    > ASCII.


    Actually, if you check back to the original question, we were talking
    about endianness in "TCP/IP," which I take to mean "in the IP family".
    It is universally big endian.

    >> How does this apply to ASCII? If an ASCII number is represented, big
    >> endian byte order simply means that the ASCII representation is
    >> transmitted in the same order as when written on a page, left to
    >> right.
    >> When ASCII is used, this is the general rule.

    >
    > In other words, there is no rule that numbers that exceed one byte are
    > sent in big-endian order. Some protocols send them that way, some send
    > them other ways.


    ASCII numbers always exceed one byte if there is more than one digit
    represented, right? It takes one byte to represent each numeral. In
    general, ASCII numbers are sent in whatever sequence they are
    represented when written down. E.g. if ASCII numbers are used in DNS, or
    in DHCP host identifiers. I call that big endian, because the most
    significant ASCII number is sent first, since that's the way these
    numbers are typically written down.

    > You didn't say it was used, you said it was a standard for the TCP
    > payload that is established by the TCP specification.


    I said it was the standard for the *IP payload*, which includes TCP. And
    it's also the standard in applications that use TCP and UDP, a tiny
    fraction of which I listed. In all fields shown in the RFCs that
    describe IP family applications, numerical quantities are sent big
    endian. (I won't rule out some odd exception here and there that I'm
    unaware of.)

    But the words of RFC 791 are not ambiguous, even if other RFCs (such as
    959) give you a certain leeway. Here are the relevant parts of RFC 791
    Appendix B:

    ---------------quote------------
    APPENDIX B: Data Transmission Order

    The order of transmission of the header and data described in this
    document is resolved to the octet level. Whenever a diagram shows a
    group of octets, the order of transmission of those octets is the normal
    order in which they are read in English. For example, in the following
    diagram the octets are transmitted in the order they are numbered.
    ....
    Whenever an octet represents a numeric quantity the left most bit in the
    diagram is the high order or most significant bit. That is, the bit
    labeled 0 is the most significant bit. For example, the following
    diagram represents the value 170 (decimal).
    ....
    Similarly, whenever a multi-octet field represents a numeric quantity
    the left most bit of the whole field is the most significant bit. When
    a multi-octet quantity is transmitted the most significant octet is
    transmitted first.
    -------------end quote-----------

    Note at the top: header and data are specified. Note that the octet
    (byte) order of transmission is specified, even if the bit order of
    transmission in each byte is not. (The bit order of transmission depends
    on L2 specifics.)

    > In any event, how could the RFC specify a particular byte order for
    > the
    > payload without specifying where the numbers begin and end? You would
    > still need another protocol layered on top of TCP to say that, yes,
    > that is a 4-byte integer, or that's a 2-byte integer.


    When RFCs describe the payload, and NTP would be an example of that,
    they always describe big endian. If the data payload of the particular
    application is not described in an RFC, then I suppose you're free to
    send anything in any order. But in that case, specifying little endian
    creates unnecessary confusion.

    Bert


  19. Re: endian of within a tcp/ip byte tramission


    Albert Manfredi wrote:

    > Similarly, whenever a multi-octet field represents a numeric quantity
    > the left most bit of the whole field is the most significant bit. When
    > a multi-octet quantity is transmitted the most significant octet is
    > transmitted first.


    In the TCP payload, there are no multi-octet fields. Please show me
    where the TCP standard defines any multi-octet fields in the payload.

    You are completely misreading this, and your misreading leads to some
    very bizarre conseqeuences.

    Any standard you are using on top of TCP will define things at the
    byte-level. So there will never be any multi-octet fields in the TCP
    payload, as far as the TCP standard is concerned. Any standard that
    failed to do so would be deficient, and every specification does this.
    SNMP does. HTTP does. FTP does.

    When you see, for example, BER explaining how to encode a multi-byte
    integer as a series of octets, that means that any protocol that layers
    BER on top of TCP (as, for example, SNMP does) *only* presents octets
    to TCP.

    Again, there are no multi-octet fields in the TCP payload. The TCP
    standard defines none, and there would be no way to tell where they
    began or ended if it did.

    DS


  20. Re: endian of within a tcp/ip byte tramission

    In article ,
    "Albert Manfredi" wrote:

    > You have a point concerning the content of the executable file file
    > being transported, and that's clearly stated in RFC 959 (see 3.1). But
    > there's no question at all that FTP is specified to be big endian byte
    > order, when it comes to its own headers, command, and reply fields,
    > which are at Layer 7. And that the same holds true for all other IP
    > applications.


    FTP doesn't have any headers, and its commands and replies are all ASCII
    text. So the concept of "endianness" doesn't really apply. The only
    thing you might be referring to is the syntax of the PORT command, which
    breaks the address and port number into octets, which are then sent as
    comma-separated decimal numbers in ASCII.

    --
    Barry Margolin, barmar@alum.mit.edu
    Arlington, MA
    *** PLEASE post questions in newsgroups, not directly to me ***
    *** PLEASE don't copy me on replies, I'll read them in the group ***

+ Reply to Thread
Page 1 of 2 1 2 LastLast