summary | shortlog | log | commit | commitdiff | tree
raw | patch | inline | side by side (parent: 794f9fe)
raw | patch | inline | side by side (parent: 794f9fe)
author | Johannes Schindelin <Johannes.Schindelin@gmx.de> | |
Sun, 23 Oct 2005 01:37:45 +0000 (03:37 +0200) | ||
committer | Junio C Hamano <junkio@cox.net> | |
Mon, 24 Oct 2005 22:13:37 +0000 (15:13 -0700) |
The current fetch/upload protocol works like this:
- client sends revs it wants to have via "want" messages
- client sends a flush message (message with len 0)
- client sends revs it has via "have" messages
- after one window (32 revs), a flush is sent
- after each subsequent window, a flush is sent, and an ACK/NAK is received.
(NAK means that server does not have any of the transmitted revs;
ACK sends also the sha1 of the rev server has)
- when the first ACK is received, client sends "done", and does not expect
any further messages
One special case, though:
- if no ACK is received (only NAK's), and client runs out of revs to send,
"done" is sent, and server sends just one more "NAK"
A smarter scheme, which actually has a chance to detect more than one
common rev, would be to send more than just one ACK. This patch implements
the server side of the following extension to the protocol:
- client sends at least one "want" message with "multi_ack" appended, like
"want 1234567890123456789012345678901234567890 multi_ack"
- if the server understands that extension, it will send ACK messages for all
revs it has, not just the first one
- server appends "continue" to the ACK messages like
"ACK 1234567890123456789012345678901234567890 continue"
until it has MAX_HAS-1 revs. In this manner, client knows when to
stop sending revs by checking for the substring "continue" (and
further knows that server understands multi_ack)
In this manner, the protocol stays backwards compatible, since both client
must send "want ... multi_ack" and server must answer with "ACK ...
continue" to enable the extension.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- client sends revs it wants to have via "want" messages
- client sends a flush message (message with len 0)
- client sends revs it has via "have" messages
- after one window (32 revs), a flush is sent
- after each subsequent window, a flush is sent, and an ACK/NAK is received.
(NAK means that server does not have any of the transmitted revs;
ACK sends also the sha1 of the rev server has)
- when the first ACK is received, client sends "done", and does not expect
any further messages
One special case, though:
- if no ACK is received (only NAK's), and client runs out of revs to send,
"done" is sent, and server sends just one more "NAK"
A smarter scheme, which actually has a chance to detect more than one
common rev, would be to send more than just one ACK. This patch implements
the server side of the following extension to the protocol:
- client sends at least one "want" message with "multi_ack" appended, like
"want 1234567890123456789012345678901234567890 multi_ack"
- if the server understands that extension, it will send ACK messages for all
revs it has, not just the first one
- server appends "continue" to the ACK messages like
"ACK 1234567890123456789012345678901234567890 continue"
until it has MAX_HAS-1 revs. In this manner, client knows when to
stop sending revs by checking for the substring "continue" (and
further knows that server understands multi_ack)
In this manner, the protocol stays backwards compatible, since both client
must send "want ... multi_ack" and server must answer with "ACK ...
continue" to enable the extension.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
upload-pack.c | patch | blob | history |
diff --git a/upload-pack.c b/upload-pack.c
index ab1981c72ae8d908e5844ea0b8f4b6e74e572bbc..c3abf7ba659b9f4957740486b8bb7aca5b1c8471 100644 (file)
--- a/upload-pack.c
+++ b/upload-pack.c
#define THEY_HAVE (1U << 0)
#define MAX_HAS 256
#define MAX_NEEDS 256
-static int nr_has = 0, nr_needs = 0;
+static int nr_has = 0, nr_needs = 0, multi_ack = 0;
static unsigned char has_sha1[MAX_HAS][20];
static unsigned char needs_sha1[MAX_NEEDS][20];
static unsigned int timeout = 0;
reset_timeout();
if (!len) {
- packet_write(1, "NAK\n");
+ if (multi_ack || nr_has == 0)
+ packet_write(1, "NAK\n");
continue;
}
len = strip(line, len);
if (!strncmp(line, "have ", 5)) {
- if (got_sha1(line+5, sha1)) {
- packet_write(1, "ACK %s\n", sha1_to_hex(sha1));
- break;
- }
+ if (got_sha1(line+5, sha1) &&
+ (multi_ack || nr_has == 1))
+ packet_write(1, "ACK %s%s\n",
+ sha1_to_hex(sha1),
+ multi_ack && nr_has < MAX_HAS ?
+ " continue" : "");
continue;
}
if (!strcmp(line, "done")) {
+ if (nr_has > 0)
+ return 0;
packet_write(1, "NAK\n");
return -1;
}
die("git-upload-pack: expected SHA1 list, got '%s'", line);
}
-
- for (;;) {
- len = packet_read_line(0, line, sizeof(line));
- reset_timeout();
- if (!len)
- continue;
- len = strip(line, len);
- if (!strncmp(line, "have ", 5)) {
- got_sha1(line+5, sha1);
- continue;
- }
- if (!strcmp(line, "done"))
- break;
- die("git-upload-pack: expected SHA1 list, got '%s'", line);
- }
- return 0;
}
static int receive_needs(void)
if (strncmp("want ", line, 5) || get_sha1_hex(line+5, sha1_buf))
die("git-upload-pack: protocol error, "
"expected to get sha, not '%s'", line);
+
+ if (strstr(line+45, "multi_ack"))
+ multi_ack = 1;
+
needs++;
}
}