August 11, 2019 11:04 AM, "Pratyush Yadav" <> wrote:

> On 10/08/19 11:47PM, Farhan Khan wrote:
>> Hi,
>> I am trying to write an implementation of git clone over ssh and am a little 
>> confused how to
>> determine a server response has ended. Specifically, after a client sends 
>> its requested 'want', the
>> server sends the pack content over. However, how does the client know to 
>> stop reading data? If I
>> run a simple read() of the file descriptor:
>> A. If I use reading blocking, the client will wait until new data is 
>> available, potentially
>> forever.
>> B. If I use non-blocking, the client might terminate reading for new data, 
>> when in reality new data
>> is in transit.
>> I do not see a mechanism to specify the size or to indicate the end of the 
>> pack content. Am I
>> missing something?
> Well, I am not very familiar with git-clone internals, but I did some
> digging around, and I think I know what answer to your problem is.
> Looking at Documentation/technical/protocol-v2.txt:34, the flush packet
> indicates the end of a message. Looking in the output section of the
> fetch command (protocol-v2.txt:342), it sends you some optional
> sections, and then the packfile and then sends a flush packet.
> So your read should stop reading data when it sees the flush packet.
> Another way would be to look at the packfile contents. Looking at
> Documentation/technical/pack-format.txt, the packfile contains the
> number of objects in the packfile, and each object entry has the object
> size. So you can stop reading after you have received the last object in
> the packfile (plus the 20-byte trailer).
> I don't know which is the better way, but the former seems like a better
> choice to me.
> --
> Regards,
> Pratyush Yadav

Hi Pratyush,

Thanks for your reply!

Unless I am mistaken, a pack file does not end in a flush_pkt. I ran some tests 
and did not see the stream end in "0000". Is there is a mistake somewhere on my 

Farhan Khan
PGP Fingerprint: 1312 89CE 663E 1EB2 179C  1C83 C41D 2281 F8DA C0DE

Reply via email to