IO::Socket client

[Rainer Weikusat]

Sure I did. Using more than 1 msg necessitates state info and probably
maintaining an open socket.

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'.

How does the state information needed to read the HTTP response above
change whether you view it as one or two (or five) messages?

You don't need state info if there's only 1 msg.
[...]

I think you just want to argue. I was responding to George's scenario:

when you want complex things like.

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

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).

 

[$Bill]

Ok, again:

Question 1: Why does "telling the server what you are going to do"
have to be in a separate message?

I never said it did - George implied that with his scenario.

Question 2: Is the above one message or two or five?

Not sure what you are referring to 'the above' - it can be one using my scenario
or more using others.

So. No, you haven't.

Yes I have - you just want to keep arguing about it.

You keep repeating this but you don't give any reason for it. The
sequence of bytes on the wire doesn't change. Why would the amount of
state info change? In any case you need two pieces of state info:

* Whether you are in the header/message 1 or the body/message 2
* If you are in the latter, how much you have already read.

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.

 

[Rainer Weikusat]

[...]

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.

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.

 

[Peter J. Holzer]

I never said it did - George implied that with his scenario.

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.

Not sure what you are referring to 'the above'

HTTP response I posted. Here it is again:

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

- it can be one using my scenario or more using others.

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.

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.

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.

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.

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]

I never said it did - George implied that with his scenario.

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.

Not sure what you are referring to 'the above'

HTTP response I posted. Here it is again:

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

- it can be one using my scenario or more using others.

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.

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.

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.

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.

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

 

[$Bill]

[...]

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.

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.

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]

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.