END when finishing FETCH
Closed this issue · 3 comments
In Data Transfer section it says:
In “dial-up mode” (FETCH command), only queued data is transferred. When transferring packets of all requested stations has completed, the server MUST append ASCII string END (without <cr><lf>) to the last packet and wait for the client to close connection.
This is a little confusing. I think what is meant is that the last packet is sent, then the 3 chars E N D are sent.
The alternative interpretation is that the E N D is part of the payload of the last packet, which I think is not correct. Would be good to clarify this.
Suggest:
In “dial-up mode” (FETCH command), only queued data is transferred. When the transfer of all packets for all requested stations has completed, the server MUST send the ASCII string END (without <cr><lf>) after the last packet and wait for the client to close connection.
Also suggest changing:
It is not allowed to send more data from server to client after END has been sent.
to
The server MUST NOT send data packets to the client after END has been sent.
Feedback from proposal team
Agreed.
Change of specification
In “dial-up mode” (FETCH command), only queued data is transferred. When transferring packets of all requested stations has completed, the server MUST append ASCII string END (without ) to the last packet and wait for the client to close connection. → In “dial-up mode” (ENDFETCH command), only queued data is transferred. When the transfer of all packets for all requested stations has completed, the server MUST send the ASCII string END (without ) after the last packet and wait for the client to close connection.¹
It is not allowed to send more data from server to client after END has been sent. → The server MUST NOT send data packets to the client after END has been sent.
Discussion
¹ Is it required that the client closes connection (eg., to ensure that the client has received all data)?
I do not think that the server side closing of the connection has any affect on whether the client receives "in flight" packets as that should be handled down at the tcp stack level. Unless someone with more low level socket knowledge objects, I think we should remove and wait for the client to close connection from that sentence. In fact it might be better for the server to send "END" and then immediately close the connection.
+1 on change