Implement server::Builder::max_send_buffer_size

[nox]

No description provided.

[nox]

I tried using wait_for_capacity to write a test but I couldn't understand how to use it in conjunction with .drive on the server side.

[nox]

@seanmonstar Do you think h2 should have a default maximum?

[nox]

Also, do you have any idea how I could write a test for this?

[nox]

I used to do this prior to calling try_assign_capacity. AFAIU that was wrong, right?

[seanmonstar]

That sounds right. The connection-level and stream-level should be updated together, but since updating the stream-level may make it exceed it's requested capacity and thus needs to check for more capacity, that must happen in-between.

A code comment about the ordering being important may be prudent.

[seanmonstar]

Do you think h2 should have a default maximum?

Hm, probably yes.

Also, it might be good (once we have it working) to compare how this change affects hyper's http2 end_to_end benchmarks, just so we know.

[seanmonstar]

I think this area needs to potentially wake up any tasks that have been waiting on "capacity", since now there is "more buffer space to use". The reason it needs to be done here, is because with flow control capacity, the connection doesn't actually get more until the peer has sent another WINDOW_UPDATE frame. So recv_window_update will notify a task there. But buffer size isn't affected by WINDOW_UPDATE frames.

[nox]

I'm not sure I understand. Why do we even call self.flow.assign_capacity(len); below that line, if we are actually supposed to wait for the peer to send another WINDOW_UPDATE frame?

[nox]

I am even more confused that we call self.flow.send_data(len); immediately afterwards we called self.flow.assign_capacity(len);.

[nox]

Doesn't that mean that self.flow.available never changes from Prioritize::pop_frame? I don't understand the logic there.

[nox]

I called assign_connection_capacity from poll_complete after the reclaim_frame call.

[nox]

The test is hanging there, and by the time h2 returns Poll::Pending, Actions::task is None so there is no way to wake up the connection task to call poll_complete from there.

[nox]

AFAIK the test is still wrong. We await for t2 before we await for t0, so t0 is pending and nothing will wake it up when t2 notifies the connection task that it has frames to send, so the send buffer size never decreases and everything gets stuck.

[nox]

Never mind I misread. That being said, the test really doesn't help much finding where the issue with my patch is :/

[nox]

h2/tests/h2-support/src/util.rs

Lines 56 to 66 in 2c53d60

	fn poll(mut self: Pin<&mut Self>, cx: &mut Context<'_>) -> Poll<Self::Output> {
	let _ = ready!(self.stream().poll_capacity(cx)).unwrap();
	let act = self.stream().capacity();
	if act >= self.target {
	return Poll::Ready(self.stream.take().unwrap().into());
	}
	Poll::Pending
	}

There, poll_capacity returns Ready(Some(0)), and capacity returns 0, so act >= self.target is false, and Poll::Pending gets returned even though nothing has been set up to wake up the task.

What do you think is wrong here? That poll_capacity returns Ready(Some(0)), or that wait_for_capacity is badly conceived, or both?