Getting started with quic_client and quic_server

[Mario H]

Hi,

I'm trying to use quic as a stand-alone transport protocol / tcp-replacement (in userspace).

Since I prefer starting with something that works, I began with compiling chromium (as suggested in the former post about »Trying to compile the sources from svn.«) The QUIC-FAQ points to »/src/net/tools/quic/« which contains a quic client and server. They can be compiled with: "ninja -C out/Debug/ quic_library quic_client quic_server"

- My first question is: Are client and server in this directory still up to date? (Since, there is also a quic directory under: »src/net/quic«)

- My second question is how to use them properly?

Starting both programs without any parameter seems to trigger some communication between them, then the client quits. But any attempt to transport some "payload" results in a crash:

In »quic_client_bin.cc« the following example can be found in the comments: "quic_client --port=6122 /index.html /favicon.ico" After adjusting the port (6121), the client crashes with: "[0917/122321:FATAL:spdy_utils.cc(123)] Check failed: !scheme.empty()." Another post in the chromium group suggests calling the client like this: "./quic_client http://<somehost>/index.html" (https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-dev/quic/chromium-dev/JOzig90Xp0I/q3NsvNEzzLwJ)

This, at least, does not crash. So if this is the right way to call the client, the comment in »quic_client_bin.cc« should be updated. But the next problem is to configure the server. There is no information where to put the files to serve, and putting them in the working directory does not work.

After startup the server prints: "[0917/123745:INFO:quic_in_memory_cache.cc(124)] Attempting to initialize QuicInMemoryCache from directory: /tmp/quic-data". But putting files into »/tmp/quic-data« results in a crash of the server on startup. In the file »quic_in_memory_cache.cc« is a comment that says: "[...] Cache directory can be generated using `wget -p --save-headers <url>", but this still results in a crash:

mkdir /tmp/quic-data
cd /tmp/quic-data
wget -p --save-headers http://google.com
cd [into the chromium dir]
./quic_server
--> crashes with "[...] Unhandled error framing HTTP."

But even if this would work, I'm wondering what the quic server is supposed to do. Why does it only have a cache-dir and what are the stored headers used for?

I'd appreciate any help guiding me to a working client-server example with QUIC.

Best regard, Mario

[Ryan Hamilton]

On Tue, Sep 17, 2013 at 4:05 AM, Mario H <goo...@mario.omnifile.org> wrote:

Hi,

I'm trying to use quic as a stand-alone transport protocol / tcp-replacement (in userspace).

Since I prefer starting with something that works, I began with compiling chromium (as suggested in the former post about »Trying to compile the sources from svn.«) The QUIC-FAQ points to »/src/net/tools/quic/« which contains a quic client and server. They can be compiled with: "ninja -C out/Debug/ quic_library quic_client quic_server"

- My first question is: Are client and server in this directory still up to date? (Since, there is also a quic directory under: »src/net/quic«)

​Yes, these stand-alone tools are up-to-date.  (Though since they're not part of the code that runs *in* the chrome browser, it's possible that there are some gotchas).​

- My second question is how to use them properly?

Starting both programs without any parameter seems to trigger some communication between them, then the client quits. But any attempt to transport some "payload" results in a crash:

In »quic_client_bin.cc« the following example can be found in the comments: "quic_client --port=6122 /index.html /favicon.ico" After adjusting the port (6121), the client crashes with: "[0917/122321:FATAL:spdy_utils.cc(123)] Check failed: !scheme.empty()." Another post in the chromium group suggests calling the client like this: "./quic_client http://<somehost>/index.html" (https://groups.google.com/a/chromium.org/forum/#!searchin/chromium-dev/quic/chromium-dev/JOzig90Xp0I/q3NsvNEzzLwJ)

​Yes, the quic client needs to fetch a fully qualified URL.  This means that <somehost> needs to match the host:port where you server is.​  I just built from source, started the quic server via:

% ./out/Debug/quic_server

Then I ran the quic client:

% ./out/Debug/quic_client http://localhost:6121/

[0919/110135:INFO:quic_client_bin.cc(38)] server port: 6121 address: 127.0.0.1 hostname: localhost

[0919/110135:INFO:quic_connection.cc(1234)]  Client: Sending packet number 1 : data bearing , encryption level: ENCRYPTION_NONE, length:529

[0919/110135:INFO:quic_connection.cc(653)]  Client: Got packet 1 with 0 acks, 0 congestions, 0 goaways, 0 rsts, 1 stream frames for 6014641088149559558

[0919/110136:INFO:quic_connection.cc(1234)]  Client: Sending packet number 2 : data bearing , encryption level: ENCRYPTION_NONE, length:527

[0919/110136:INFO:quic_session.cc(379)]  Client: num_streams: 0. activating 3

[0919/110136:INFO:quic_connection.cc(1234)]  Client: Sending packet number 3 : data bearing , encryption level: ENCRYPTION_INITIAL, length:91

[0919/110136:INFO:reliable_quic_stream.cc(456)] Done writing to stream 3

[0919/110136:INFO:quic_connection.cc(653)]  Client: Got packet 2 with 0 acks, 0 congestions, 0 goaways, 0 rsts, 1 stream frames for 6014641088149559558

[0919/110136:INFO:quic_connection.cc(1234)]  Client: Sending packet number 4 :  ack only , encryption level: ENCRYPTION_FORWARD_SECURE, length:37

[0919/110136:INFO:aes_128_gcm_12_decrypter_nss.cc(343)] My_Decrypt failed: NSS error -8190

[0919/110136:INFO:quic_connection.cc(653)]  Client: Got packet 3 with 1 acks, 1 congestions, 0 goaways, 0 rsts, 0 stream frames for 6014641088149559558

[0919/110136:INFO:quic_connection.cc(653)]  Client: Got packet 4 with 0 acks, 0 congestions, 0 goaways, 0 rsts, 1 stream frames for 6014641088149559558

[0919/110136:INFO:quic_connection.cc(1234)]  Client: Sending packet number 5 :  ack only , encryption level: ENCRYPTION_FORWARD_SECURE, length:37

[0919/110136:INFO:quic_connection.cc(653)]  Client: Got packet 5 with 0 acks, 0 congestions, 0 goaways, 0 rsts, 1 stream frames for 6014641088149559558

[0919/110136:INFO:reliable_quic_stream.cc(286)] Done reading from stream 3

[0919/110136:INFO:reliable_quic_stream.cc(290)] Closing stream: 3

[0919/110136:INFO:quic_session.cc(263)]  Client: Closing stream 3

[0919/110136:INFO:quic_connection.cc(879)] Sending RST_STREAM: 3 code: 3

[0919/110136:INFO:quic_connection.cc(1234)]  Client: Sending packet number 6 : data bearing , encryption level: ENCRYPTION_FORWARD_SECURE, length:22

[0919/110136:INFO:quic_session.cc(263)]  Client: Closing stream 3

[0919/110136:INFO:quic_session.cc(267)]  Client: Stream is already closed: 3

[0919/110136:INFO:quic_connection.cc(653)]  Client: Got packet 6 with 1 acks, 1 congestions, 0 goaways, 0 rsts, 0 stream frames for 6014641088149559558

[0919/110136:INFO:quic_connection.cc(1234)]  Client: Sending packet number 7 :  ack only , encryption level: ENCRYPTION_FORWARD_SECURE, length:37

[0919/110136:INFO:quic_connection.cc(653)]  Client: Got packet 7 with 1 acks, 1 congestions, 0 goaways, 0 rsts, 0 stream frames for 6014641088149559558

[0919/110136:INFO:tcp_cubic_sender.cc(73)] Start update end sequence number @6

[0919/110136:INFO:quic_connection.cc(1587)]  Client: Force closing with error QUIC_PEER_GOING_AWAY (16) 

[0919/110136:INFO:quic_connection.cc(1234)]  Client: Sending packet number 8 : data bearing , encryption level: ENCRYPTION_FORWARD_SECURE, length:37

So this looks reasonable.

This, at least, does not crash. So if this is the right way to call the client, the comment in »quic_client_bin.cc« should be updated. But the next problem is to configure the server. There is no information where to put the files to serve, and putting them in the working directory does not work.

After startup the server prints: "[0917/123745:INFO:quic_in_memory_cache.cc(124)] Attempting to initialize QuicInMemoryCache from directory: /tmp/quic-data". But putting files into »/tmp/quic-data« results in a crash of the server on startup. In the file »quic_in_memory_cache.cc« is a comment that says: "[...] Cache directory can be generated using `wget -p --save-headers <url>", but this still results in a crash:

mkdir /tmp/quic-data
cd /tmp/quic-data
wget -p --save-headers http://google.com
cd [into the chromium dir]
./quic_server
--> crashes with "[...] Unhandled error framing HTTP."

Hm. I do see this too.  I'll debug and get a fix in place soon.

​​

But even if this would work, I'm wondering what the quic server is supposed to do. Why does it only have a cache-dir and what are the stored headers used for?

The stand-alone quic server is simply an in-memory static web server.  It serves up the data from /tmp/quic-data (though I think there is a command line flag to change that)​ in response to web requests.  Does that help?

Cheers,

Ryan

​​

I'd appreciate any help guiding me to a working client-server example with QUIC.

Best regard, Mario

--
You received this message because you are subscribed to the Google Groups "QUIC Prototype Protocol Discussion group" group.
To unsubscribe from this group and stop receiving emails from it, send an email to proto-quic+...@chromium.org.
To post to this group, send email to proto...@chromium.org.
For more options, visit https://groups.google.com/a/chromium.org/groups/opt_out.

[Ryan Hamilton]

Hah!  So the problem is that wget's output is inconstant.  It include the following header:

Transfer-Encoding: chunked

​​But, of course the body is not check encoded.  If you remove this header, it'll work fine.  

By the way, you can add a header like:

X-Original-Url: http://www.google.com/

This tells the quic server that file being loaded, can be fetched as the specified URL.  Then you can fetch it via:

./out/Debug/quic_client --port=6121 --hostname=localhost http://www.google.com/

​Sound reasonable?

Cheers,

Ryan

[Mario H]

Great, thank you very much for your help. This helps me a lot!

But I still have an additional question: How can I tell it actually worked?

I don't see the quic_client writing any files to disk or saying "IT WORKS". ;-)

Also I still get errors on the server like, for example:

- "[0919/210215:INFO:quic_connection.cc(648)] Server: Stream reset with error QUIC_BAD_APPLICATION_PAYLOAD"
- "[0919/210215:INFO:aes_128_gcm_12_decrypter_nss.cc(343)] My_Decrypt failed: NSS error -8190"

Is this just normal, since I can see them in your output, too?

Cheers, Mario

[Ryan Hamilton]

On Thu, Sep 19, 2013 at 12:12 PM, Mario H <goo...@mario.omnifile.org> wrote:

Great, thank you very much for your help. This helps me a lot!

But I still have an additional question: How can I tell it actually worked?

I don't see the quic_client writing any files to disk or saying "IT WORKS". ;-)

​Heh, yeah.  instead, it would tell you if there were an error.  But this is lame :>  I'd be thrilled to get a patch which makes it more clear what is going on.

 

[Mario H]

Am Montag, 23. September 2013 19:53:03 UTC+2 schrieb r...@chromium.org:

On Thu, Sep 19, 2013 at 12:12 PM, Mario H wrote:

Great, thank you very much for your help. This helps me a lot!

But I still have an additional question: How can I tell it actually worked?

I don't see the quic_client writing any files to disk or saying "IT WORKS". ;-)

​Heh, yeah.  instead, it would tell you if there were an error.  But this is lame :>  I'd be thrilled to get a patch which makes it more clear what is going on.

 

 

What about this one?

Index: quic_spdy_client_stream.cc
===================================================================
--- quic_spdy_client_stream.cc    (Revision 223005)
+++ quic_spdy_client_stream.cc    (Arbeitskopie)
@@ -14,6 +14,52 @@
 namespace net {
 namespace tools {
 
+
+/// very simple buffer for printing headers
+class StringBuffer {
+ public:
+
+  /// constructor
+  StringBuffer() :
+    is_new_line(true)
+  {
+  }
+
+  void Write(const char* p, size_t size) {
+    // drop long string pieces (e.g. cookies)
+    if ( size > 50 )
+    {
+      string_ += "[...]";
+    }
+
+    // regular string piece
+    else
+    {
+      std::string s = std::string(p, size);
+
+      // start every line with ">> "
+      if ( is_new_line )
+        s = ">> " + s;
+
+      if ( s == "\r\n" )
+        is_new_line = true;
+      else
+        is_new_line = false;
+
+      // append string piece
+      string_ += s;
+    }
+  }
+
+  /// return whole buffer as read-only string
+  const std::string& string() {return string_;}
+
+ private:
+  std::string string_;
+  bool is_new_line;
+};
+
+
 static const size_t kHeaderBufInitialSize = 4096;
 
 QuicSpdyClientStream::QuicSpdyClientStream(QuicStreamId id,
@@ -54,6 +100,23 @@
              mutable_data()->size() != headers().content_length()) {
     Close(QUIC_BAD_APPLICATION_PAYLOAD);
   }
+
+  // debug output: print response
+  if ( response_headers_received_ )
+  {
+    StringBuffer buffer;
+    headers().WriteHeaderAndEndingToBuffer(&buffer);
+
+    LOG(INFO) << "Connection terminated. The following data was received during the session:\n"
+      << "RESPONSE HEADER:\n" << buffer.string() << "[END OF RESPONSE HEADER]\n\n"
+      << "PAYLOAD DATA: " << data().size() << " bytes.\nEXCERPT: "
+      << data().substr(0,20) << " [...] " << data().substr(data().length() - 15, std::string::npos);
+//      << "[END OF DATA]";
+  }
+  else
+  {
+    LOG(WARNING) << "Connection terminated. NO PAYLOAD DATA RECEIVED!";
+  }
 }
 
 ssize_t QuicSpdyClientStream::SendRequest(const BalsaHeaders& headers,
@@ -62,6 +125,12 @@
   SpdyHeaderBlock header_block =
       SpdyUtils::RequestHeadersToSpdyHeaders(headers);
 
+  // debug output: print request header
+  StringBuffer buffer;
+  headers.WriteHeaderAndEndingToBuffer(&buffer);
+  LOG(INFO) << "SENDING REQUEST HEADER:\n" << buffer.string() << "[END OF REQUEST HEADER]";
+
+
   string headers_string;
   if (session()->connection()->version() >= QUIC_VERSION_9) {
     headers_string = session()->compressor()->CompressHeadersWithPriority(
@@ -96,6 +165,8 @@
     Close(QUIC_BAD_APPLICATION_PAYLOAD);
     return -1;
   }
+ 
+  response_headers_received_ = true;
 
   size_t delta = read_buf_len - len;
   if (delta > 0) {


Also I think this fixes a bug, too. Since quic_client was acting strange because "response_headers_received_ = true" was never set.

Best, Mario

[Ryan Hamilton]

Howdy Mario,

Thanks for the patch!  I didn't forget about you :>  I just landed https://codereview.chromium.org/25043005/ which hopefully address your issues.  I ended up taking a slightly different route...

Cheers,

Ryan

[Mario H]

Great, thank you.

I also noticed you updated the help-comments (in the source) and that client and server can now print a brief help when called with "-h".

Cheers,

Mario

[Pradeep Nayak]

We are still unable to host data of /tmp/quic-data even after correcting the headers as mentioned above. Any alternatives on how we go about this ? I am using Ubuntu 12.10.

[Ryan Hamilton]

Can you say more about the errors you are seeing?

[Pradeep Nayak]

Hi Ryan,

The problem is very similar to the one described earlier here: https://groups.google.com/a/chromium.org/forum/#!topic/proto-quic/lAdf4qvU-LY

1. I do, wget -p --save-headers http://google.com

2. Attempted to start the quic_server and it crashes.

3. I then followed your instructions by removing the line: Transfer-Encoding: chunked 

4. I start the server again and it crashes with the same error

Any alternatives ? Do let me know if you need more details. Thanks

Regards,
Pradeep Nayak

http://pradeepnayak.in
http://twitter.com/_prdp

[Ryan Hamilton]

Odd.  Here's what I did which helped me find the T-E header problem.  I removed "most" of the headers in the file and then attempted to start the QUIC server.  That worked.  Then I added some back until it failed.  That let me find the particular header that was the problem.  I suggest you follow a similar process.  If you can narrow it down to just the headers that's causing problems, you can either remove it, or let me know and I can see what needs to be done to tweak the code.

[Mario H]

Please try: ./quic_server --quic_in_memory_cache_dir=/tmp/quic-data

[Brian Prodoehl]

I had an issue with passing an actual path with --quic_in_memory_cache_dir, and after some snooping around with strace I just found that running quic_server from within /tmp/quic-data, and passing in --quic_in_memory_cache_dir=. worked.  I posted the scripts I use to generate the data and run the server here: https://github.com/Connectify/benchmarking/tree/master/scripts

[Pradeep Nayak]

Thanks Brian. Your suggestion indeed did work. I am really not sure whats the reason behind to start it that way. Do you have any idea what may be the problem ?

Regards,
Pradeep Nayak

http://pradeepnayak.in
http://twitter.com/_prdp

[Brian Prodoehl]

That's good to hear. I don't remember what it was doing with the path, but I was also having problems with an assert on where a / was. I used strace to see where it was looking when I specified /tmp/quic-data, and it was prepending it with something.

[eledra Nguyen]

Hi,

I tried to compile the latest version of quic_server. I did remove the header, create /tmp/quic-data and passing parameters as suggested. 

However it still crashed with the "[...] Unhandled error framing HTTP."

Is there anything new that I need to check as well ? Currently I fetch header from Google.com.

Best regards,

Vào 02:29:36 UTC+2 Thứ bảy, ngày 23 tháng mười một năm 2013, Brian Prodoehl đã viết:

[yuanyua...@gmail.com]

I have some same issue with you.

[eledra Nguyen]

Well, i managed to build quic_client and quic_server by commenting out this line in quic_in_memory_cache.cc:

DCHECK_LT(0, path_start) 

After that, just wget with header Google.com, put X-Original-Url and it will work.

Vào 23:47:09 UTC+2 Thứ tư, ngày 12 tháng hai năm 2014, Yuanyuan Zhou đã viết:

[Yuanyuan Zhou]

Thanks!!! So you used quic_client to talk to the quic server and it worked?

Some few questions in details:

Did you save index.html directly under /tmp/quic-data or /tmp/quic-data/www.google.com?

Did you start the server with quic_server --quic_in_memory_cache_dir=/tmp/quic-data

and start the client with quic_client http://localhost:6121?

Thanks so much!

[eledra Nguyen]

mkdir ~/quic-data

cd ~/quic-data

wget -p --save-headers "http://google.com"

edit google.com/index.html, add: X-Original-Url: http://google.com/

Comment out DCHECK_LT(0,path_start) in quic_in_memory_cache.cc

*note: i don't know why, but path_start is the full path to index.html. In my case it's /home/..../quic-data/google.com/index.html. And they expect that path_start does not start with "/" character. So far, commenting out this line work for me

ninja quic_client quic_server

./quic_server --quic_in_memory_cache_dir=/home/..../quic-data

After this, quic_server will prompt a message like this:

"Inserting 'http://google.com/' into QuicInMemoryCache"

That means our "X-Original-Url" is in the memory cache

We get it with ./quic_client http://google.com/

Vào 02:45:22 UTC+2 Thứ năm, ngày 13 tháng hai năm 2014, Yuanyuan Zhou đã viết:

Thanks!!! So you used quic_client to talk to the quic server and it worked?

Some few questions in details:

Did you save index.html directly under /tmp/quic-data or /tmp/quic-data/www.google.com?

Did you start the server with quic_server --quic_in_memory_cache_dir=/tmp/quic-data

and start the client with quic_client http://localhost:6121?

Thanks so much!

On Wednesday, February 12, 2014 7:20:43 PM UTC-5, eledra Nguyen wrote:

[Yuanyuan Zhou]

Thanks again. :)

I got there by adding some cout. The problem was due to the url in memory cache. It seems that you set up the environment on a local machine. Are you able to use client on a remote machine from the server?

[eledra Nguyen]

Yes, I am working with 2 machines.

./quic_client --address="x.x.x.x" http://google.com

Vào 08:45:43 UTC+2 Thứ năm, ngày 13 tháng hai năm 2014, Yuanyuan Zhou đã viết:

[Ryan Young]

Is there a final tutorial how to make it work with quic_client talking to quic_server?

I still got "[0308/005542:FATAL:quic_in_memory_cache.cc(51)] Unhandled error framing HTTP." following Nguyen's method.

@Ryan, any further suggestion regarding to this issue?

[eledra Nguyen]

Did you remove the "Transfer-Encoding: chunked" header ?

Vào 19:00:17 UTC+2 Thứ sáu, ngày 07 tháng ba năm 2014, Ryan Young đã viết:

[Ryan Young]

I managed to work it out as following but failed:

--------------------------

cd /tmp/quic-data

wget -p --save-headers "http://google.com"

edit google.com/index.html:

add: "X-Original-Url: http://google.com/"

delete: "Transfer-Encoding: chunked"

Comment out DCHECK_LT(0,path_start) in quic_in_memory_cache.cc

ninja -C out/Debug/ quic_client quic_server

./quic_server --quic_in_memory_cache_dir=/tmp/quic-data

[0310/164323:FATAL:quic_in_memory_cache.cc(51)] Unhandled error framing HTTP.

...

--------------------------

Any suggestion?

[Ryan Young]

That was caused by another html file I generated before and forgot to remove it from the directory, thanks Eledra.

[Yuanyuan Zhou]

I encounter the HTTP framing errors with wget -p --save-headers www.wikipedia.org

Is there any general approach in debugging this problem?

Thanks!