and also to turn the client into a server that can be controlled remotely (client part
not implemented yet)
Change on 2015/01/13 by vpai <vpai@google.com>
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=83863541
- adds _grpc_ensure_gcloud_ssh that creates the ~/.ssh/gcloud_compute_engine
key file if it does not exist
- update all the grpc_** commands that use ssh to call this
Checked that the opensource version still builds.
Just addressing core for now. We will do c++ later.
Change on 2015/01/12 by jboeuf <jboeuf@google.com>
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=83804014
- Looks like we should have cleaned this header before... I don't think it's a
big deal though...
- Removing the tests from the opensource package as well (these are very much
[] specific for now).
Change on 2015/01/12 by jboeuf <jboeuf@google.com>
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=83801766
Allows tests to bind to port 0 and still have clients connect to them.
Change on 2015/01/12 by ctiller <ctiller@google.com>
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=83800669
Update location of rpc_method.cc on the Makefile
Change on 2015/01/12 by rsilvera <rsilvera@google.com>
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=83786942
the server.
Verify that method, scheme, and te trailers are present, and error out if not.
Complain if content-type doesn't match the format, but don't error out.
This currently, for now, blindly allows all three schemes (grpc, http, https)
without verification, although that will change once the C implementation
finishes switching to http/https.
Cloned from CL 82558661 by 'g4 patch'.
Original change by klempner@klempner:grpc_metadata:808:citc on 2014/12/19 18:41:47.
Change on 2015/01/12 by ctiller <ctiller@google.com>
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=83785251
Split encoding into two phases: a collection phase to decide on what is allowed
(by flow control) to be sent, and a framing phase when the data is actually
sent. Perform the second phase outside of the transport mutex (but serially,
guarded by t->writing) and make flow control callbacks during that phase.
This will allow us to make further transport level calls in response to flow
control callbacks, and will be needed by the forthcoming async api for C++.
Change on 2015/01/12 by ctiller <ctiller@google.com>
-------------
Created by MOE: http://code.google.com/p/moe-java
MOE_MIGRATED_REVID=83774409