草庐IT

read-write

全部标签

tcp - BufWriter::write() 不会将字节写入 TcpStream

我用Rust编写了一个echo服务器和客户端。这是我的代码:服务器:usestd::net::{TcpListener,TcpStream};usestd::thread;usestd::io::Write;usestd::io::BufReader;usestd::io::BufRead;usestd::io::BufWriter;fnhandle_connection(stream:TcpStream){letstream_clone=stream.try_clone().unwrap();letmutreader=BufReader::new(stream);letmutwrit

python - 在 python 中读取套接字时,os.read 和 socket.recv 之间有什么区别吗?

假设我有一个socket。这两行代码有什么区别?第1行:os.read(some_socket.fileno(),1024)第2行:some_socket.recv(1024)...除了第一个不能在Windows上运行的事实。换句话说,我可以用第二行代替第一行吗?我有一个代码库还没有真正用Windows测试过,这导致了麻烦。 最佳答案 第1行使用带下划线的文件描述符来读取套接字,因此它是平台相关的。使用第2行,因为它是一种可移植的、多平台的方式来完成同样的事情。强制性:如果您正在做任何严肃的事情,最好避免处理低级套接字。他们很难做到

c - Fork Process/Read Write through pipe 慢

回答https://stackoverflow.com/a/12507520/962890太琐碎了..args!但收到了很多好的信息。感谢大家。编辑github链接:https://github.com/MarkusPfundstein/stream_lame_testing原帖我有一些关于通过管道进行IPC的问题。我的目标是接收每个TCP/IP流的MP3数据,通过LAME将其解码为wav,进行一些数学运算并将其存储在磁盘上(作为wav)。我在整个过程中都使用非阻塞IO。让我有点恼火的是,tcp/ip读取比管道线槽快得多。当我发送~3MBmp3时,文件会在几秒钟内在客户端读取。一开始,

linux - epoll TCP 边缘触发最后一次 read(2) 调用的必要性

给定一个非阻塞TCP套接字,如果调用read(sock,buf,bufLen)返回一个值bufLen,然后等待边缘触发的EPOLLIN事件是否安全?还是我必须再次调用read以确保它为零或EAGAIN?在我的测试中,当我删除最后一个调用时,一切都保持正常,我只是想知道它是否在任何地方或Linux源代码中得到保证,以及我是否可以摆脱额外的调用。 最佳答案 你的问题在man7epoll中得到了回答。如您所见,它取决于套接字类型(数据包/流):Q9使用EPOLLET标志(边沿触发行为)时,是否需要连续读/写文件描述符直到EAGAIN?A9

c++ - boost::asio::async_read 在换行符上返回文件结尾错误

我正在尝试使用async_read和async_write向服务器发出简单的tcp请求并设置超时。问题是async_read在尝试读取直到传输结束时给出错误,在第一个'\n'上它返回错误(文件结束)。逐行读取字符串时(当eots->at(last_request)='\n')时,它成功读取了整个响应。if(eots->at(last_request)=="")//readuntilend{boost::asio::async_read(socket_,input_buffer_,boost::asio::transfer_at_least(1)//readuntillendorerro

c - TCP 套接字 : Can read() still fail with EINTR when select() indicates there are data available?

我正在使用select()从TCP套接字进行非阻塞read()。当select()指示有数据可供读取时,我不确定在read()之后是否还需要处理EINTR。 最佳答案 是的,绝对是。select函数是一个状态报告函数,它会在您调用select和您注意到它的返回值之间的某个时间报告某物的状态。它绝对没有任何future保证。这是一个非常普遍的误解。但是认为select确保future的操作将提供某些特定结果的想法与认为检查磁盘上是否有可用空间意味着future的写入不会失败一样是错误的。根据其判断,即使您认为有足够的可用空间,该实现也

c - 服务器 TCP 卡在 read() 上

我正在尝试让服务器接收来自TCP客户端的消息。问题是,一旦我关闭客户端的套接字,我只会在服务器端收到消息。服务器端的读取函数如下:char*read_socket(intfd){intbytesRcvd,aux;char*buffer=(char*)malloc(BUFFSIZE*sizeof(char));bytesRcvd=read(fd,buffer,BUFFSIZE);aux=bytesRcvd;while(bytesRcvd>0){if((bytesRcvd=read(fd,&buffer[aux],BUFFSIZE))我知道(通过printfs)它卡在了线上:bytesRc

c# - NetworkStream.Write 阻塞到什么时候?

我能想到这些可能的答案:直到数据被写入IP堆栈中的某个内部缓冲区。直到数据通过网络发送。直到从另一台机器收到接收确认。 最佳答案 直到数据写入发送端的发送缓冲区。因此,如果缓冲区已满,它将阻塞。如果由于网络问题或接收方的接收缓冲区已满而尚未传输数据,则发送缓冲区可能已满。您可以进行一个实验:创建发送方和接收方,将发送方的套接字发送缓冲区设置为较小的值,并将接收方的接收缓冲区设置为较小的值。开始发送,接收方接受连接,但不接收。当发送的字节数约为SenderSendBuffer+ReceiverReceiveBuffer时,socket

http - std::io::TcpStream::read_as_string 返回空字符串

我想在Rust中创建一个类似curl的函数。到目前为止,这是我使用的代码:matchUrl::parse(url){Ok(u)=>{matchTcpStream::connect(u.host.as_slice(),80){Ok(mutsocket)=>{letreq=format!("GET{:s}HTTP/1.1\r\nHost:{:s}\r\nAccept:*/*\r\nContent-Length:0\r\nContent-Type:aplication/x-www-form-urlencoded\r\n",u.path.path.as_slice(),u.host);sock