IO::Socket client

Discussion in 'Perl Misc' started by George Mpouras, Apr 28, 2014.

  1. If 'an open socket' wasn't supposed to be maintained, the whole question
    would be moot as 'closing the socket' would/ could mark the end of 'the
    current message'.
    I think you misunderstood that and that George was providing simplified
    examples of his actual messages, eg, that 'hey client, I am going to
    send you a file so big' is supposed to refer to something like sending a
    header with a command code of 'file falling from the sky' and a size,
    followed by the file data and that '++ok server' is the client telling
    the server that it has processed/ downloaded the file and is ready for
    the next protocol exchange (unusually organized here because the
    server seems to be active instead of acting on client requests but even
    this might be an impression accidentally caused by the textual form).
     
    Rainer Weikusat, May 2, 2014
    #21
    1. Advertisements

  2. George Mpouras

    $Bill Guest

    I never said it did - George implied that with his scenario.
    Not sure what you are referring to 'the above' - it can be one using my scenario
    or more using others.
    Yes I have - you just want to keep arguing about it.
    If the control is in the header of the msg, there is no need to maintain
    state because the operation is completed at the time of the msg. Using
    a different protocol (implied by George's scenario):

    -- now lets exchange some small control messages
    ++ ok server
    -- now get a big serialized data structure
    ++ not everything is defined
    -- ops client I did not like your answer, wait for three messages for me

    You have to remember info between msgs because the transaction is not yet
    complete. And that's the last time I'm saying it. If you think George's scenario
    doesn't imply that, then we disagree on what George said/implied and that's OK too.

    I;m not going over it again.
     
    $Bill, May 2, 2014
    #22
    1. Advertisements

  3. [...]
    This can only ever be true (for IPv4) if each 'msg', including all
    protocol-specific framing, has a size of at most 64K and in practice,
    for TCP, the limit is 1460 bytes or less. As soon as the SDUs become
    larger than that, state has to be maintained for processing them as
    this will require multiple receive operations.
     
    Rainer Weikusat, May 2, 2014
    #23
  4. No, I don't think he did. He wrote:

    | -- hey client, I am going to send you a file so big
    | ++ ok server

    (and some similar exchanges). AFAICS he didn't imply anywhere that "I am
    going to send you a file so big" and the file itself were two separate
    messages. But you apparently assumed that he did, so I pointed out that
    you were making unfounded assumptions.

    HTTP response I posted. Here it is again:

    200 OK
    Content-Type: text/html
    Size: 1234

    Now I'm not sure what you mean by "it". Assuming you mean the HTTP
    response: Right. It could be one or several. Now why does processing the
    absolutely identical sequence of bytes more state information when you
    view it as several messages instead of only one? It is exactly the same
    and of course it can be processed in exactly the same way.

    You still need to maintain state while processing the message. And - I
    repeat myself - you need exactly the same state. You need to be able to
    recognize the end of the HTTP header and the end of the HTTP body (for
    which you need information from the HTTP header (the size) and a counter
    for how many bytes of the body you have already read. This doesn't
    change whether you view that as one message consisting of two parts or
    two separate messages.

    Yes, we disagree on that. I have now repeatedly asked why you think that
    George said/implied that and you have never answered that question.

    hp
     
    Peter J. Holzer, May 2, 2014
    #24
  5. No, I don't think he did. He wrote:

    | -- hey client, I am going to send you a file so big
    | ++ ok server

    (and some similar exchanges). AFAICS he didn't imply anywhere that "I am
    going to send you a file so big" and the file itself were two separate
    messages. But you apparently assumed that he did, so I pointed out that
    you were making unfounded assumptions.

    HTTP response I posted. Here it is again:

    200 OK
    Content-Type: text/html
    Size: 1234

    Now I'm not sure what you mean by "it". Assuming you mean the HTTP
    response: Right. It could be one or several. Now why does processing the
    absolutely identical sequence of bytes need more state information when
    you view it as several messages instead of only one? It is exactly the
    same and of course it can be processed in exactly the same way.

    You still need to maintain state while processing the message. And - I
    repeat myself - you need exactly the same state. You need to be able to
    recognize the end of the HTTP header and the end of the HTTP body (for
    which you need information from the HTTP header (the size) and a counter
    for how many bytes of the body you have already read. This doesn't
    change whether you view that as one message consisting of two parts or
    two separate messages.

    Yes, we disagree on that. I have now repeatedly asked why you think that
    George said/implied that and you have never answered that question.

    hp
     
    Peter J. Holzer, May 2, 2014
    #25
  6. George Mpouras

    $Bill Guest

    If you assume record oriented msgs rather than streams, you could accumulate
    larger msgs with virtually minimal state info with sufficient storage
    (requiring mult I/O operations of course).

    It would require accumulating the ENTIRE msg before starting to process it OR
    to process part of the msg (knowing what it is) and maintaining some small
    state info while accumulating the rest of the data.

    File xfers pretty much always require some state info to keep track of what
    file each msg is part of or you could segment the file and avoid that too
    for the most part.

    UDP messages could also be used, but I prefer to impose a record header and
    use TCP/IP streams - you just need sufficient buffering or keeping of state
    info (which is pretty much mandatory for an unsegmented file xfer).
     
    $Bill, May 3, 2014
    #26
  7. George Mpouras

    $Bill Guest

    One last time Peter - my take of George's scenario was that it was overly
    complicated requiring multiple transactions to complete which I deemed
    unnecessary if true. If your take was different, that's fine and there
    is no need for to keep arguing a moot point.

    I was not referring to the underlying protocol, but the task level protocol.

    Whether you have to read one or more segments of data (mult I/O transactions)
    wasn't the issue and would require buffering and state info to accomplish in
    a stream env if there weren't sufficient smarts above that layer to handle it
    (eg: segmenting a file xfer).

    I won't respond to any more discussion on this subject without a change in
    specific topic.
     
    $Bill, May 3, 2014
    #27
    1. Advertisements

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments (here). After that, you can post your question and our members will help you out.