reactor
/
ptth
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
ptth/crates/ptth_forwarding_relay/src/main.rs

209 lines
4.3 KiB
Rust
Raw Normal View History

:construction: wip: idea for tunneling TCP over HTTP There's a lot of missing pieces, but the big picture is like this: - Use 2 completely separate HTTP streams, and try to keep them alive as long as possible, each in basically half-duplex mode - Each stream has a long-running PUT and GET, sort of like station307 - Each end has to be terminated by a native app that either connects to a local TCP server, or acts as a local TCP server - No clue how it would work for multiple connections on the same port. Poorly, I guess? - It's probably gonna run like garbage because we're splitting TCP into 2 TCP streams, and although backpressure might work, the ACKs will be less efficient. And the congestion control might get confused My only goal is to tunnel Tracy over it, so that I can have that remotely.
2021-01-12 00:22:55 +00:00
use std::{
:construction: wip: I was working on some port-forwarding idea. It was going to be generic over TCP and use 2 HTTP streams, one each way. The plan's written down somewhere.
2021-01-19 23:24:50 +00:00
collections::HashMap,
:construction: wip: idea for tunneling TCP over HTTP There's a lot of missing pieces, but the big picture is like this: - Use 2 completely separate HTTP streams, and try to keep them alive as long as possible, each in basically half-duplex mode - Each stream has a long-running PUT and GET, sort of like station307 - Each end has to be terminated by a native app that either connects to a local TCP server, or acts as a local TCP server - No clue how it would work for multiple connections on the same port. Poorly, I guess? - It's probably gonna run like garbage because we're splitting TCP into 2 TCP streams, and although backpressure might work, the ACKs will be less efficient. And the congestion control might get confused My only goal is to tunnel Tracy over it, so that I can have that remotely.
2021-01-12 00:22:55 +00:00
sync::Arc,
time::Duration,
};
:arrow_up: deps: upgrade everything to Tokio 1.2.0 And pretend I didn't completely goober the Docker build somehow
2021-03-06 21:15:41 +00:00
use futures_util::StreamExt;
:construction: wip: idea for tunneling TCP over HTTP There's a lot of missing pieces, but the big picture is like this: - Use 2 completely separate HTTP streams, and try to keep them alive as long as possible, each in basically half-duplex mode - Each stream has a long-running PUT and GET, sort of like station307 - Each end has to be terminated by a native app that either connects to a local TCP server, or acts as a local TCP server - No clue how it would work for multiple connections on the same port. Poorly, I guess? - It's probably gonna run like garbage because we're splitting TCP into 2 TCP streams, and although backpressure might work, the ACKs will be less efficient. And the congestion control might get confused My only goal is to tunnel Tracy over it, so that I can have that remotely.
2021-01-12 00:22:55 +00:00
use hyper::{
Body,
Method,
Request,
Response,
StatusCode,
};
use tokio::{
spawn,
:construction: wip: I was working on some port-forwarding idea. It was going to be generic over TCP and use 2 HTTP streams, one each way. The plan's written down somewhere.
2021-01-19 23:24:50 +00:00
sync::{
RwLock,
mpsc,
},
:construction: wip: idea for tunneling TCP over HTTP There's a lot of missing pieces, but the big picture is like this: - Use 2 completely separate HTTP streams, and try to keep them alive as long as possible, each in basically half-duplex mode - Each stream has a long-running PUT and GET, sort of like station307 - Each end has to be terminated by a native app that either connects to a local TCP server, or acts as a local TCP server - No clue how it would work for multiple connections on the same port. Poorly, I guess? - It's probably gonna run like garbage because we're splitting TCP into 2 TCP streams, and although backpressure might work, the ACKs will be less efficient. And the congestion control might get confused My only goal is to tunnel Tracy over it, so that I can have that remotely.
2021-01-12 00:22:55 +00:00
time::interval,
};
:arrow_up: deps: upgrade everything to Tokio 1.2.0 And pretend I didn't completely goober the Docker build somehow
2021-03-06 21:15:41 +00:00
use tokio_stream::wrappers::ReceiverStream;
:construction: wip: idea for tunneling TCP over HTTP There's a lot of missing pieces, but the big picture is like this: - Use 2 completely separate HTTP streams, and try to keep them alive as long as possible, each in basically half-duplex mode - Each stream has a long-running PUT and GET, sort of like station307 - Each end has to be terminated by a native app that either connects to a local TCP server, or acts as a local TCP server - No clue how it would work for multiple connections on the same port. Poorly, I guess? - It's probably gonna run like garbage because we're splitting TCP into 2 TCP streams, and although backpressure might work, the ACKs will be less efficient. And the congestion control might get confused My only goal is to tunnel Tracy over it, so that I can have that remotely.
2021-01-12 00:22:55 +00:00
use tracing::{
info, trace,
};
use tracing_subscriber::{
fmt,
fmt::format::FmtSpan,
EnvFilter,
};
:white_check_mark: test: fix tests
2021-01-19 23:27:33 +00:00
#[derive (Default)]
:construction: wip: I was working on some port-forwarding idea. It was going to be generic over TCP and use 2 HTTP streams, one each way. The plan's written down somewhere.
2021-01-19 23:24:50 +00:00
struct RelayState {
connections: HashMap <String, ConnectionState>,
client_opaques: HashMap <String, String>,
server_opaques: HashMap <String, String>,
}
/*
HTTP has 2 good pause points:
- Client has uploaded request body, server has said nothing
- Server has sent status code + response headers
Because we want to stream everything, there is no point in a single HTTP
req-resp pair
having both a streaming request body and a streaming response body.
To move the state machine, the first request from client and server must not
be streaming.
With all that in mind, the r
*/
enum ConnectionState {
// We got 1 connection from the client. We need a 2nd to form the upstream.
WaitForUpstream (String, String),
// We got 2 connections from the client. We need the server to accept
// by sending its downstream.
WaitForAccept (String, String, String),
Connected (String, String, String, String),
}
// An established connection has 4 individual HTTP streams
struct EstablishedConnection {
// Request body of 'upstream' call
client_up: String,
// Response body of 'connect' call
client_down: String,
:construction: wip: idea for tunneling TCP over HTTP There's a lot of missing pieces, but the big picture is like this: - Use 2 completely separate HTTP streams, and try to keep them alive as long as possible, each in basically half-duplex mode - Each stream has a long-running PUT and GET, sort of like station307 - Each end has to be terminated by a native app that either connects to a local TCP server, or acts as a local TCP server - No clue how it would work for multiple connections on the same port. Poorly, I guess? - It's probably gonna run like garbage because we're splitting TCP into 2 TCP streams, and although backpressure might work, the ACKs will be less efficient. And the congestion control might get confused My only goal is to tunnel Tracy over it, so that I can have that remotely.
2021-01-12 00:22:55 +00:00
:construction: wip: I was working on some port-forwarding idea. It was going to be generic over TCP and use 2 HTTP streams, one each way. The plan's written down somewhere.
2021-01-19 23:24:50 +00:00
// Response body of 'listen' call
server_up: String,
// Request body of 'accept' call
server_down: String,
:construction: wip: idea for tunneling TCP over HTTP There's a lot of missing pieces, but the big picture is like this: - Use 2 completely separate HTTP streams, and try to keep them alive as long as possible, each in basically half-duplex mode - Each stream has a long-running PUT and GET, sort of like station307 - Each end has to be terminated by a native app that either connects to a local TCP server, or acts as a local TCP server - No clue how it would work for multiple connections on the same port. Poorly, I guess? - It's probably gonna run like garbage because we're splitting TCP into 2 TCP streams, and although backpressure might work, the ACKs will be less efficient. And the congestion control might get confused My only goal is to tunnel Tracy over it, so that I can have that remotely.
2021-01-12 00:22:55 +00:00
}
:rotating_light: fix a bunch of easy clippy warnings
2021-03-21 03:34:47 +00:00
#[derive (Default)]
:construction: wip: idea for tunneling TCP over HTTP There's a lot of missing pieces, but the big picture is like this: - Use 2 completely separate HTTP streams, and try to keep them alive as long as possible, each in basically half-duplex mode - Each stream has a long-running PUT and GET, sort of like station307 - Each end has to be terminated by a native app that either connects to a local TCP server, or acts as a local TCP server - No clue how it would work for multiple connections on the same port. Poorly, I guess? - It's probably gonna run like garbage because we're splitting TCP into 2 TCP streams, and although backpressure might work, the ACKs will be less efficient. And the congestion control might get confused My only goal is to tunnel Tracy over it, so that I can have that remotely.
2021-01-12 00:22:55 +00:00
pub struct HttpService {
state: Arc <RelayState>
}
impl HttpService {
pub async fn serve (&self, port: u16) -> Result <(), hyper::Error> {
use std::net::SocketAddr;
use hyper::{
server::Server,
service::{
make_service_fn,
service_fn,
},
};
let make_svc = make_service_fn (|_conn| {
let state = self.state.clone ();
async {
Ok::<_, String> (service_fn (move |req| {
let state = state.clone ();
Self::handle_all (req, state)
}))
}
});
let addr = SocketAddr::from(([127, 0, 0, 1], port));
let server = Server::bind (&addr)
.serve (make_svc)
;
server.await
}
async fn handle_all (req: Request <Body>, state: Arc <RelayState>)
-> Result <Response <Body>, anyhow::Error>
{
if req.method () == Method::GET {
return Self::handle_gets (req, &*state).await;
}
:construction: wip: further POC
2021-01-12 01:20:36 +00:00
if req.method () == Method::POST {
return Self::handle_posts (req, &*state).await;
}
:construction: wip: idea for tunneling TCP over HTTP There's a lot of missing pieces, but the big picture is like this: - Use 2 completely separate HTTP streams, and try to keep them alive as long as possible, each in basically half-duplex mode - Each stream has a long-running PUT and GET, sort of like station307 - Each end has to be terminated by a native app that either connects to a local TCP server, or acts as a local TCP server - No clue how it would work for multiple connections on the same port. Poorly, I guess? - It's probably gonna run like garbage because we're splitting TCP into 2 TCP streams, and although backpressure might work, the ACKs will be less efficient. And the congestion control might get confused My only goal is to tunnel Tracy over it, so that I can have that remotely.
2021-01-12 00:22:55 +00:00
Ok::<_, anyhow::Error> (Response::builder ()
.body (Body::from ("hello\n"))?)
}
async fn handle_gets (req: Request <Body>, state: &RelayState)
-> Result <Response <Body>, anyhow::Error>
{
:rotating_light: fix a bunch of easy clippy warnings
2021-03-21 03:34:47 +00:00
let (tx, rx) = mpsc::channel (1);
:construction: wip: idea for tunneling TCP over HTTP There's a lot of missing pieces, but the big picture is like this: - Use 2 completely separate HTTP streams, and try to keep them alive as long as possible, each in basically half-duplex mode - Each stream has a long-running PUT and GET, sort of like station307 - Each end has to be terminated by a native app that either connects to a local TCP server, or acts as a local TCP server - No clue how it would work for multiple connections on the same port. Poorly, I guess? - It's probably gonna run like garbage because we're splitting TCP into 2 TCP streams, and although backpressure might work, the ACKs will be less efficient. And the congestion control might get confused My only goal is to tunnel Tracy over it, so that I can have that remotely.
2021-01-12 00:22:55 +00:00
spawn (async move {
:arrow_up: deps: replace ulid with rusty_ulid so I can drop rand 0.6.x
2021-03-21 03:09:44 +00:00
let id = rusty_ulid::generate_ulid_string ();
:construction: wip: idea for tunneling TCP over HTTP There's a lot of missing pieces, but the big picture is like this: - Use 2 completely separate HTTP streams, and try to keep them alive as long as possible, each in basically half-duplex mode - Each stream has a long-running PUT and GET, sort of like station307 - Each end has to be terminated by a native app that either connects to a local TCP server, or acts as a local TCP server - No clue how it would work for multiple connections on the same port. Poorly, I guess? - It's probably gonna run like garbage because we're splitting TCP into 2 TCP streams, and although backpressure might work, the ACKs will be less efficient. And the congestion control might get confused My only goal is to tunnel Tracy over it, so that I can have that remotely.
2021-01-12 00:22:55 +00:00
trace! ("Downstream {} started", id);
Self::handle_downstream (tx).await.ok ();
trace! ("Downstream {} ended", id);
});
Ok::<_, anyhow::Error> (Response::builder ()
:arrow_up: deps: upgrade everything to Tokio 1.2.0 And pretend I didn't completely goober the Docker build somehow
2021-03-06 21:15:41 +00:00
.body (Body::wrap_stream (ReceiverStream::new (rx)))?)
:construction: wip: idea for tunneling TCP over HTTP There's a lot of missing pieces, but the big picture is like this: - Use 2 completely separate HTTP streams, and try to keep them alive as long as possible, each in basically half-duplex mode - Each stream has a long-running PUT and GET, sort of like station307 - Each end has to be terminated by a native app that either connects to a local TCP server, or acts as a local TCP server - No clue how it would work for multiple connections on the same port. Poorly, I guess? - It's probably gonna run like garbage because we're splitting TCP into 2 TCP streams, and although backpressure might work, the ACKs will be less efficient. And the congestion control might get confused My only goal is to tunnel Tracy over it, so that I can have that remotely.
2021-01-12 00:22:55 +00:00
}
:construction: wip: further POC
2021-01-12 01:20:36 +00:00
async fn handle_posts (req: Request <Body>, state: &RelayState)
-> Result <Response <Body>, anyhow::Error>
{
:arrow_up: deps: replace ulid with rusty_ulid so I can drop rand 0.6.x
2021-03-21 03:09:44 +00:00
let id = rusty_ulid::generate_ulid_string ();
:construction: wip: further POC
2021-01-12 01:20:36 +00:00
trace! ("Upstream {} started", id);
let mut body = req.into_body ();
while let Some (Ok (item)) = body.next ().await {
println! ("Chunk: {:?}", item);
}
trace! ("Upstream {} ended", id);
Ok::<_, anyhow::Error> (Response::builder ()
.body (Body::from ("hello\n"))?)
}
:arrow_up: deps: upgrade everything to Tokio 1.2.0 And pretend I didn't completely goober the Docker build somehow
2021-03-06 21:15:41 +00:00
async fn handle_downstream (tx: mpsc::Sender <anyhow::Result <String>>) -> Result <(), anyhow::Error> {
:construction: wip: idea for tunneling TCP over HTTP There's a lot of missing pieces, but the big picture is like this: - Use 2 completely separate HTTP streams, and try to keep them alive as long as possible, each in basically half-duplex mode - Each stream has a long-running PUT and GET, sort of like station307 - Each end has to be terminated by a native app that either connects to a local TCP server, or acts as a local TCP server - No clue how it would work for multiple connections on the same port. Poorly, I guess? - It's probably gonna run like garbage because we're splitting TCP into 2 TCP streams, and although backpressure might work, the ACKs will be less efficient. And the congestion control might get confused My only goal is to tunnel Tracy over it, so that I can have that remotely.
2021-01-12 00:22:55 +00:00
let mut int = interval (Duration::from_secs (1));
let mut counter = 0u64;
loop {
int.tick ().await;
tx.send (Ok::<_, anyhow::Error> (format! ("Counter: {}\n", counter))).await?;
counter += 1;
}
}
}
#[tokio::main]
async fn main () -> Result <(), anyhow::Error> {
use std::time::Duration;
use tokio::{
spawn,
time::interval,
};
fmt ()
.with_env_filter (EnvFilter::from_default_env ())
.with_span_events (FmtSpan::CLOSE)
.init ()
;
:rotating_light: fix a bunch of easy clippy warnings
2021-03-21 03:34:47 +00:00
let service = HttpService::default ();
:construction: wip: idea for tunneling TCP over HTTP There's a lot of missing pieces, but the big picture is like this: - Use 2 completely separate HTTP streams, and try to keep them alive as long as possible, each in basically half-duplex mode - Each stream has a long-running PUT and GET, sort of like station307 - Each end has to be terminated by a native app that either connects to a local TCP server, or acts as a local TCP server - No clue how it would work for multiple connections on the same port. Poorly, I guess? - It's probably gonna run like garbage because we're splitting TCP into 2 TCP streams, and although backpressure might work, the ACKs will be less efficient. And the congestion control might get confused My only goal is to tunnel Tracy over it, so that I can have that remotely.
2021-01-12 00:22:55 +00:00
info! ("Starting relay");
Ok (service.serve (4003).await?)
}
:construction: wip: I was working on some port-forwarding idea. It was going to be generic over TCP and use 2 HTTP streams, one each way. The plan's written down somewhere.
2021-01-19 23:24:50 +00:00
#[cfg (test)]
mod tests {
use super::*;
#[test]
fn state_machine () {
:white_check_mark: test: fix tests
2021-01-19 23:27:33 +00:00
// assert! (false);
:construction: wip: I was working on some port-forwarding idea. It was going to be generic over TCP and use 2 HTTP streams, one each way. The plan's written down somewhere.
2021-01-19 23:24:50 +00:00
}
}