dcsimg
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 3 123 LastLast
Results 1 to 15 of 39

Thread: network protocols

  1. #1
    Join Date
    Nov 2002
    Location
    Los Angeles, California
    Posts
    3,863

    network protocols

    Can someone please explain the advantage of using a tokenized
    stream protocol (so packets are deliminated by say newline).

    The only one I can think of is platform independence.

    A major drawback seems to be security concerns.


    Why, oh why, resort to such a method instead of prepending the
    packet size?

    Is it just lazy *** programmers?
    Wakeup in the morning and kick the day in the teeth!! Or something like that.

    "i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."

  2. #2
    Join Date
    Sep 2002
    Location
    Belarus - Tirol, Austria
    Posts
    647

    Re: network protocols

    Originally posted by souldog
    The only one I can think of is platform independence.

    A major drawback seems to be security concerns.

    Why, oh why, resort to such a method instead of prepending the
    packet size?

    Is it just lazy *** programmers?
    What platform independence do U mean?
    I donot see any advantages on the first view as compared with other one (point the packet size).
    That's merely the simplest way to implement not so a difficult client/server protocol but not so appropriate in many cases, though.

    I prefer to use packets with special header which has a field describing a size of the packet.
    "UNIX is simple; it just takes a genius to understand its simplicity!"

  3. #3
    Join Date
    May 1999
    Location
    Southern California
    Posts
    12,266
    I am not familiar with such things enough to help, but I don't understand why prepending the packet size enables security and a tokenized stream protocol does not. Also, is it possible to use both? I probably misunderstand, but if I understand well enough, it should be possible to use both and then the receiving algorithm could have two levels; one that ensures the data is the correct size and another that parses the data. The parsing could be done by existing software, such as std::stringstream.
    "Signature":
    My web site is Simple Samples.
    C# Corner Editor

  4. #4
    Join Date
    Sep 2002
    Location
    Belarus - Tirol, Austria
    Posts
    647
    Originally posted by Sam Hobbs
    I am not familiar with such things enough to help, but I don't understand why prepending the packet size enables security and a tokenized stream protocol does not. Also, is it possible to use both? I probably misunderstand, but if I understand well enough, it should be possible to use both and then the receiving algorithm could have two levels; one that ensures the data is the correct size and another that parses the data. The parsing could be done by existing software, such as std::stringstream.
    Both methods are used to know the size of packet in the stream. So if U know a size of the packet (from header of packet), U need no any token to mark the end of packet. There is no need to use both of them.
    "UNIX is simple; it just takes a genius to understand its simplicity!"

  5. #5
    Join Date
    May 1999
    Location
    Southern California
    Posts
    12,266
    Originally posted by dimm_coder
    Both methods are used to know the size of packet in the stream. So if U know a size of the packet (from header of packet), U need no any token to mark the end of packet. There is no need to use both of them.
    This is actually dependent on the question of why prepending the packet size enables security and a tokenized stream protocol does not. If a tokenized stream protocol can be as secure as without an additional prepended packet size, then it is my understanding that the size of the packet is not relevant to this thread.
    "Signature":
    My web site is Simple Samples.
    C# Corner Editor

  6. #6
    Join Date
    Jan 2004
    Posts
    206

    Re: network protocols

    Originally posted by souldog
    Can someone please explain the advantage of using a tokenized
    stream protocol (so packets are deliminated by say newline).

    The only one I can think of is platform independence.

    A major drawback seems to be security concerns.


    Why, oh why, resort to such a method instead of prepending the
    packet size?

    Is it just lazy *** programmers?
    By looking at the title, I first thought it is about network routing protocols such as RIP and OSPF.

    Can you explain further about the platform independence and security issues? From what I see, you are talking about the different way of packing data into packets, and I don't really understand what has it got to do with platform independency and security ?

  7. #7
    Join Date
    Jan 2004
    Posts
    206

    Re: Re: network protocols

    Originally posted by Homestead
    Souldog, Nina have a file but not sure if it is useful for Souldog, perhaps Souldog already had it or read it...it s big, Nina couldnt attach it, so please come there and download
    ForASoulOfPetLover



    Regards,
    -Fiona
    Hmm....pardon my ignorance, can you explain what has the attached document to do with what souldog is asking? The paper is just introducing a platform independent C++ development environment, while souldog is asking about different ways of packing data into a stream for inter-process communication. I can't really corelate the two of them.


  8. #8
    Join Date
    Sep 2002
    Posts
    1,747
    I see no reason to ever use delimiters. That would just limit the character set you could use for the rest of the packet string. I've only ever prepended the size.
    */*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/*/

    "It's hard to believe in something you don't understand." -- the sidhi X-files episode

    galathaea: prankster, fablist, magician, liar

  9. #9
    Join Date
    Sep 2002
    Location
    Belarus - Tirol, Austria
    Posts
    647
    Originally posted by galathaea
    I see no reason to ever use delimiters. That would just limit the character set you could use for the rest of the packet string. I've only ever prepended the size.
    I've always been implementing my code the same way too.
    The only one case to use markers I see is to send simple string lines (text data, not binary) and the marker here is '\n', because in this case the rest of string have no any '\n'.
    But in any case, to point a size of packet is better way.
    "UNIX is simple; it just takes a genius to understand its simplicity!"

  10. #10
    Join Date
    Sep 2002
    Location
    Maryland - Fear The Turtle!
    Posts
    7,537
    Originally posted by galathaea
    I see no reason to ever use delimiters. That would just limit the character set you could use for the rest of the packet string. I've only ever prepended the size.
    well I was waiting for souldogs response before I chimmed in...

    because I guess I want clarification. It kinda all depends there guys...on what your doing.

    are we talking tokenized as in...

    foo|bar|num|longstring|bah
    more|delimited|data|here
    ENDOFPACKETTOKEN

    ?

    as far as security, matters not if it's tokenized or sized packed in the first two bytes. It matters if it's encrypted or not. Sniff Sniff

  11. #11
    Join Date
    Nov 2002
    Location
    Los Angeles, California
    Posts
    3,863
    Ok. First I don't have a problem, I was just belly aching because
    a protocol I had written got changed to use deliminators (for
    no good reason) and now I have to rewrite a server application
    (No big deal)

    Security (I use the word very loosely)
    It seems to me a first line of defense ( a simplistic one) against
    data corruption and maybe more is to limit the size of messages
    you are willing to accept on a socket. This is clearly not possible
    in a bare bones, simplistic, newline deliminated stream. You don't
    know how much you are going to get until you have gotten all
    of it. Obviuosly other methods can be used. I did not mean to
    indicate the deliminated streams could not be made secure.


    Platform independence
    Well if the stream consists of newline deliminated ascii strings
    then big endian little endian does not come into play ( am I
    wrong about this?) It seems like a crude way around doing byte
    swapping.


    Most of all if you prepend the size then the stream is natuarlly
    packetized as it is read in. There is no string parsing. I think it is
    more elegant.

    Anyway I started this b*tch without thinking much so take it or leave it. Personally I pass everthing in binary with a header that includes the size.
    Wakeup in the morning and kick the day in the teeth!! Or something like that.

    "i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."

  12. #12
    Join Date
    Nov 2002
    Location
    Los Angeles, California
    Posts
    3,863
    I didn't mean security in the proper way. I take it back. Just little
    checks I do on packets coming in so my server/client doesn't
    go down on bad or malicious data. I know it can be done in either
    case.

    Unfortunately this new protocol provides no convenient mechanisms.
    Wakeup in the morning and kick the day in the teeth!! Or something like that.

    "i don't want to write leak free code or most efficient code, like others traditional (so called expert) coders do."

  13. #13
    Join Date
    Sep 2002
    Location
    Maryland - Fear The Turtle!
    Posts
    7,537
    Originally posted by souldog


    Most of all if you prepend the size then the stream is natuarlly
    packetized as it is read in. There is no string parsing. I think it is
    more elegant.
    well have to reach back in my memory banks and dust off that old chip...but a good example of why you would use tokienized streams would be the HL7 format.

    not to say you couldn't do HL7 the other way, but it is more flexible to add new segments of data, and parse variable segments, whereas teh parsing code only needs to recognize that well that's not a segment it recognizes, and moves along until it finds one it can parse....

  14. #14
    Join Date
    Sep 2002
    Location
    Belarus - Tirol, Austria
    Posts
    647
    Originally posted by Mick
    well I was waiting for souldogs response before I chimmed in...
    I was waiting too to know what he meant saying about platform independence and security issues. But seems he is out of there and cannot answer or smth.

    are we talking tokenized as in...

    foo|bar|num|longstring|bah
    more|delimited|data|here
    ENDOFPACKETTOKEN
    ?
    as far as security, matters not if it's tokenized or sized packed in the first two bytes. It matters if it's encrypted or not. Sniff Sniff
    The question is related to different ways (ok, 2 ways here) of sending a variable sized packets via the streaming protocol (such as TCP).
    There are 2 ways if U want to send the packet:
    1) U choose some marker to pinpoint the end of packet (sometimes is useful for sending string lines in the simple client/server communication).
    So client is sending data
    "long long string line blalala \n"
    '\n' is a marker.
    Server has to read data from socket until he gets the char == '\n', now it knows there is the end of packet and it can process data.

    2) we put some header with data size before the data.
    The simplest case:
    [header (4 bytes)][data (variable size == value of header]

    So server first read 4 bytes and then it knows how many bytes in the following packet it has to read before processing it.

    The 2-nd case is much more flexible and useful.

    I donot think he means some security issues corresponding to data encrypting.
    One common problem with 1-st method is that as someone donot know how much data he have to read to complete the packet , there can be some problems with buffer overflowing or memory using (if someone donot pay enough attention while codding that code).
    "UNIX is simple; it just takes a genius to understand its simplicity!"

  15. #15
    Join Date
    Sep 2002
    Location
    Maryland - Fear The Turtle!
    Posts
    7,537
    just refreshing my memory on the byte ordering, and nearly spewed my coffee on this...


    You can avoid the work of converting byte orders in the following situations:

    blah...
    blah...
    blah...

    You can port the server to MFC.
    This is fairly easy to do, and the result is usually smaller, faster code. For information, see the MFC Migration Kit, which is included with Visual C++.
    Should have read, you can easily bloat your code and slow it down considerably by porting it to MFC.

    /Easily amused once more

Page 1 of 3 123 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width




On-Demand Webinars (sponsored)