rust TcpStream 为什么设计读写一体

[bli22ard]

fn main(){
    let mut ts1=TcpStream::connect(("127.0.0.1", 6666)).unwrap();
    //读写全都在一起
    ts1.write("hello".as_bytes()).unwrap();
    let mut buf=[0;1024];
    ts1.read(&mut buf).unwrap();
    //这样设计，在一些情况不方便

    //1 两个 TcpStream 需要全双工拷贝
    let mut ts2=TcpStream::connect(("127.0.0.1", 6667)).unwrap();
    //这里不得不进行 clone
    let mut ts11=ts1.try_clone().unwrap();
    let mut ts22=ts2.try_clone().unwrap();
    thread::spawn(move||{
       std::io::copy(&mut ts1,&mut ts2).unwrap();
    });

    thread::spawn(move||{
        std::io::copy(&mut ts22,&mut ts11).unwrap();
    });
    // 以下两种情况以开发一个 http server 为场景
    //2 当需要将 TcpStream 使用 BufReader  和  BufWriter 封装构造一个结构体给上层使用
    
    struct Req{
        br:BufReader<TcpStream>,
        bw:BufWriter<TcpStream>,
    }
    //3 如果不进行 buf 封装，底层处理也不能使用 buf 进行读取，因为 buf 读取可能会读取超过底层处理的数据的长度，这样底层
    // 只能使用非 buf 方式进行读取，效率就比较低下
    struct Req1{
        ts:TcpStream
    }
    
    
}

目前我能想到的 TcpStream 读写一体，是为了 drop 时候自动关闭 tcp 连接，但是这样确实带来了诸多不便。 同样 BufReader 、BufWriter 在 new 的时候传&TcpStream ，不能生成一个具有所有权的 br 、bw ，会依赖&TcpStream 。TcpStream 为什么不提供一个 getWriter 和 getReader 两个分离的函数呢？

[nagisaushio]

可以用 BufReader<Arc<TcpStream>>

[SingeeKing]

BufReader/BufWriter+ cloned TcpStream 有什么问题吗？

毕竟底层是一个 fd ，就算提供你想要的 get_reader 和 get_writer 底层肯定还是一个 clone ，和自己 clone 相比也没啥提升

[PTLin]

你的想法也没什么问题。标准库没提供，只能手动 clone ，但是 tokio 提供了你想要的功能。
https://docs.rs/tokio/latest/tokio/net/struct.TcpStream.html#method.split

[capric]

使用 into_split 可以分离读写
https://docs.rs/tokio/latest/tokio/net/struct.TcpStream.html#method.into_split
可以参考这里
https://github.com/FutureOrientedGB/gbt_sip_server/blob/09628a99b89038b65257ad3ea3fc29c45337a01a/src/sip/server.rs#L123

[bli22ard]

@nagisaushio BufReader 是没问题，但是 BufWriter 我试了下不行。因为 BufWriter<W: ?Sized + Write> 而 Arc<TcpStream> 没有实现 Write 。arc 套 buf 看起来只能实现 Reader 不能实现 Writer 。

[bli22ard]

@SingeeKing 一些资料上说，TcpStream try_clone 采用底层操作系统的 dup （在 Unix 上）或 DuplicateHandle （在 Windows 上）来创建一个新的文件描述符，该描述符指向同一个底层套接字，这样会占用一个文件描述符。另外这样调用 try_clone 不够直观。

[bli22ard]

@PTLin
@capric tokio 现在还没用， 不过这个 split 够优雅。 看来这个阻塞 io 下没有一个好的方式来处理这个分离的问题。不知道 tokio split 底层具体实现的原理的是什么

[SingeeKing]

@bli22ard 对，它是要 dup 的不然 drop 会出问题；如果真的很在意文件描述符可以自己用 Rc/Arc 包一层

[PTLin]

别钻牛角尖了，本来 os 上的 socket 就没有可以设定只能只读/只写的接口，介于这个原因标准库才没搞什么像是 tokio 里 split 那种只读只写的结构，和你上一个问的为什么&File 可以读写数据一个理由，就是更贴近 os 端的设计导致的。
所有什么只能读或者只能写的接口全都是上层语言或者库的抽象，你要想搞什么只读只写自己包一下就完事了，try_clone 在 Linux 就是 dup 系 syscall ，让多个不同 fd 指向同一个 fdtable 里的 file ，操作 clone 出来的新 TcpStream 和你操作原先的没有任何区别，两个指向的都是一个 socket file 。

[PTLin]

@PTLin 最后有口误，是让不同的 fd 对于的 fdtable 里的条目指向同一个 file 。

[capric]

@bli22ard 实现在这里，就是很简单的 Arc 和 clone
```rust
/// Owned read half of a [`TcpStream`], created by [`into_split`].
///
/// Reading from an `OwnedReadHalf` is usually done using the convenience methods found
/// on the [`AsyncReadExt`] trait.
///
/// [`TcpStream`]: TcpStream
/// [`into_split`]: TcpStream::into_split()
/// [`AsyncReadExt`]: trait@crate::io::AsyncReadExt
#[derive(Debug)]
pub struct OwnedReadHalf {
inner: Arc<TcpStream>,
}

/// Owned write half of a [`TcpStream`], created by [`into_split`].
///
/// Note that in the [`AsyncWrite`] implementation of this type, [`poll_shutdown`] will
/// shut down the TCP stream in the write direction. Dropping the write half
/// will also shut down the write half of the TCP stream.
///
/// Writing to an `OwnedWriteHalf` is usually done using the convenience methods found
/// on the [`AsyncWriteExt`] trait.
///
/// [`TcpStream`]: TcpStream
/// [`into_split`]: TcpStream::into_split()
/// [`AsyncWrite`]: trait@crate::io::AsyncWrite
/// [`poll_shutdown`]: fn@crate::io::AsyncWrite::poll_shutdown
/// [`AsyncWriteExt`]: trait@crate::io::AsyncWriteExt
#[derive(Debug)]
pub struct OwnedWriteHalf {
inner: Arc<TcpStream>,
shutdown_on_drop: bool,
}

pub(crate) fn split_owned(stream: TcpStream) -> (OwnedReadHalf, OwnedWriteHalf) {
let arc = Arc::new(stream);
let read = OwnedReadHalf {
inner: Arc::clone(&arc),
};
let write = OwnedWriteHalf {
inner: arc,
shutdown_on_drop: true,
};
(read, write)
}
```

[bli22ard]

@PTLin 本来读写分开不应该占用两个文件描述符，也不需要 dup syscall 。感觉 safe 代码没法实现读写分开有所有权。参考 @capric 尝试用 Arc<TcpStream> ，但是 Write Trait 的 fn write(&mut self, buf: &[u8]) -> Result<usize>; 需要一个 &mut self ，inner 的 Arc 提供不了可变借用。实现这个分离感觉只能 unsafe 代码

[bli22ard]

多次尝试，通过 arc 确实可以实现，因为 impl Write for &TcpStream 有一个这样的实现，它就只需要 &TcpStream 的&mut &TcpStream 就可以了，arc 可以提供&TcpStream 的所有权 所以就可以调用到&TcpStream 实现的 write 方法。

实现代码如下

use std::io::{Read, Write};
use std::net::TcpStream;
use std::sync::Arc;

pub struct OwnerWriteTcpStream {
inner:Arc<TcpStream>
}

impl Write for OwnerWriteTcpStream {
fn write(&mut self, buf: &[u8]) -> std::io::Result<usize> {
(&*self.inner).write(buf)
}

fn flush(&mut self) -> std::io::Result<()> {
(&*self.inner).flush()

}
}

pub struct OwnerReadTcpStream {
inner:Arc<TcpStream>
}

impl Read for OwnerReadTcpStream {
fn read(&mut self, buf: &mut [u8]) -> std::io::Result<usize> {
(&*self.inner).read(buf)
}
}

pub struct OwnerTcpStream(TcpStream);

impl OwnerTcpStream {
pub fn new(stream:TcpStream) -> Self {
OwnerTcpStream(stream)
}
pub fn split(self) -> (OwnerReadTcpStream, OwnerWriteTcpStream) {
let arc_read=Arc::new(self.0);
let arc_write=arc_read.clone();
let read=OwnerReadTcpStream{inner: arc_read};
let write=OwnerWriteTcpStream{inner: arc_write};
(read,write)
}
}

这个回复 markdown 用不了，不知道为什么

[PTLin]

@bli22ard 我不是让你用 dup 实现 split ，我是指 dup 之后两个 fd 也是指向的一个 vfs 这个概念，再结合你上个问的&File 问的问题你应该理解为什么有 impl Write for &TcpStream 了吧。

[bli22ard]

@PTLin 有点理解了， 这里如果不是 impl Write for &TcpStream ，那 arc 就没法实现共享 tcpstream 进行写入，&File 可能也是基于这个和 drop 关闭资源考虑吧

[PTLin]

@bli22ard 关键是你要明白，为什么你 Arc TcpStream 配合对&TcpStream 实现的 Write trait 可以实现 split 以用来实现一个线程读一个线程写抽象。
是因为对 Linux 来讲，fd 对应的 socket file 或者普通 file 本身就是可以多个线程/进程并发读写的，因为这个能力所以才有了 Rust 可以抽象出来的可 Send TcpStream 以及&TcpStream Write Read ，进而可以通过 Arc TcpStream 实现 split 。

[bli22ard]

@PTLin 在 c 里面，fd 就是个 int ， 放到 write 和 read 函数都可以， 不管这个 fd 在哪个线程被并发调用，我之前奇怪的是，很多语言，java 、golang 、c 、都可以将读写分开进行处理，rust 这不能分开太难受了，我要实现一个 http proxy ，需要两个 tcpstream 的 读写在两个线程互相 copy ，所以就有了此贴。有了 OwnerTcpStream 方便了很多。
不过个人感觉，标准库，不应该去实现 impl Write for &TcpStream ，而是应该给 tcpstream 提供函数可以获取 ReadStream 和 WriteStream 他们两个持有相同值类型 fd ，这样 api 更为友好。最后感谢各位的回复，谢谢大家🙏

[fakeshadow]

讨论设计问题不要从你当前的需求出发，而是要把其他需求也考虑进去。比如你认为标准库应该提供 split ，那么它应该如何实现呢？

[bli22ard]

@fakeshadow 读写在不同线程处理在很多场景都需要啊， 比如代理软件，p2p 共享软件。实现的话， 我能想到的是，ReadStream 和 WriteStream 共同持有底层 fd ， 这个 fd 使用 arc 记录引用次数。当 arc drop 时候，close 掉 fd 。ReadStream 和 WriteStream drop 时候，shutdown 掉对应的 read write

[fakeshadow]

@bli22ard Rust 是系统级的语言，除了你说的应用场景还有其他的情况，例如:
1.没有原子变量的平台，例如某些嵌入式，他们没法使用 Arc
2.没有堆分配器的平台，这些平台和 1 类有些重合，他们不仅没法使用 Arc ，还无法使用任何依赖堆分配的智能指针。
3.不希望支付 Arc 开销的应用场景，比如单线程并发读写

如果标准库只是简单的套 Arc ，那么其 split API 对上面两个应用场景就是毫无价值的，他们还是要自己实现其常见的 split 方法，例如:
```
fn split(stream: &TcpStream) -> (ReadHalf<'_>, WriteHalf<'_> {
// 常用于栈上协程
}

fn split(stream: &Rc<TcpStream>) -> (ReadHalf, WriteHalf) {
// 常用于单线程
}
```

你说的应用场景是重要的，但 Rust 标准库的设计不能仅仅关注在某些重要领域而忽视其他的需求。这时候你反观标注库的实现，就会发现对内部可变的文件实现 Read, Write 是一个折中的方案，以上情况都可以简单的利用其满足自己的需求。你说它完美吗？那肯定不是，我相信也会有更好的实现方式。但在更好的设计被提出之前，我觉得标准库的实现是正确的。

[bli22ard]

@fakeshadow 就算嵌入式，不支持 arc ， 那同样也可以屏蔽 split ，嵌入式基本不支持 thread ，那标准库还不是 thread 也提供了，我认为嵌入式场景不是设计成读写一体的主要原因