← Back to branch summary

~bzr-pqm/bzr/bzr.dev

« back to all changes in this revision

Viewing changes to doc/developers/network-protocol.txt

  • Committer: Patch Queue Manager
  • Date: 2014-09-22 19:14:34 UTC
  • mfrom: (6598.1.2 bzr)
  • Revision ID: pqm@pqm.ubuntu.com-20140922191434-6bbnpnxi5jab4vim
(richard-wilbur) Allows launchpad APIs to use proxies by default(Paul Gear).
 (Paul Gear)

Show diffs side-by-side

added added

removed removed

Lines of Context:
doc/developers/network-protocol.txt
11
11
Overview
12
12
========
13
13
 
14
 
The smart protocol provides a way to send a requests and corresponding
 
14
The smart protocol provides a way to send requests and corresponding
15
15
responses to communicate with a remote bzr process.
16
16
 
17
17
Layering
103
103
The domain logic is in `bzrlib.remote`: `RemoteBzrDir`, `RemoteBranch`,
104
104
and so on.
105
105
 
106
 
There is also an plain file-level transport that calls remote methods to
 
106
There is also a plain file-level transport that calls remote methods to
107
107
manipulate files on the server in `bzrlib.transport.remote`.
108
108
 
109
109
Protocol description
317
317
 
318
318
  (Discussion) We're discussing having the byte segments be not just a
319
319
  method for sending a stream across the network, but actually having them
320
 
  be preserved in the rpc from end to end.  This may be useful when
 
320
  be preserved in the RPC from end to end.  This may be useful when
321
321
  there's an iterator on one side feeding in to an iterator on the other,
322
322
  if it avoids doing chunking and byte-counting at two levels, and if
323
323
  those iterators are a natural place to get good granularity.  Also, for
369
369
  sent.
370
370
 
371
371
  This relies on the client being able to read back from the server while
372
 
  it's writing.  This is technically difficult for http but feasible over
373
 
  a socket or ssh.
 
372
  it's writing.  This is technically difficult for HTTP but feasible over
 
373
  a socket or SSH.
374
374
 
375
375
  We'd need a clean way to pass this back to the request method, even
376
376
  though it's presumably in the middle of doing its body iterator.
400
400
  happening out of order, or mixed requests happening at the same time.
401
401
 
402
402
  Wonder how our network performance would have turned out now if we'd
403
 
  done full-duplex from the start, and ignored hpss over http.  We have
404
 
  pretty good (readonly) http support just over dumb http, and that may be
 
403
  done full-duplex from the start, and ignored hpss over HTTP.  We have
 
404
  pretty good (read-only) HTTP support just over dumb HTTP, and that may be
405
405
  better for many users.
406
406
 
407
407
 
422
422
that includes any repository that might need to be referenced, and the
423
423
client needs to know about a root directory beyond which it cannot ascend.
424
424
 
425
 
Servers run over ssh will typically want to be able to access any path the
 
425
Servers run over SSH will typically want to be able to access any path the
426
426
user can access.  Public servers on the other hand (which might be over
427
 
http, ssh or tcp) will typically want to restrict access to only a
 
427
HTTP, SSH or TCP) will typically want to restrict access to only a
428
428
particular directory and its children, so will want to do a software
429
429
virtual root at that level.  In other words they'll want to rewrite
430
430
incoming paths to be under that level (and prevent escaping using ../