C#资源暂时无法在linux上的dotnet核心上使用阻塞套接字
特定的代码包括手动打开套接字连接，并通过临时将套接字设置为非阻塞来实现超时，移动到Connect方法，轮询套接字直到它连接，但还包括用于超时的退出路径。
当传递非阻塞连接方法时，会引发一个异常，该异常表示“如果我是阻塞套接字，我会在这里阻塞”（在技术上称为“eAgain”，字符串“resource permental unavailable”被绑定）。我捕捉到该异常，如果它是“wouldblock”，则忽略该异常并继续（轮询连接是否完成或超时是否发生）。在linux上，我以某种方式获得了“临时可用的资源”，尽管我捕捉到了这个错误代码。
共有1个答案
套接字的本机错误代码在每个OS上都是不同的，甚至在不同风格的UNIX上也是不同的。当我们使用MONO进行跨平台时，它会自动将本机错误代码调整为windows错误代码，以便它们与SocketeRorr枚举匹配。Dotnet核心不这样做。
（现在）有三种方法来获取SocketException的错误代码。
- ErrorCode（直接指向NativeErrorCode)
- NativeErrorCode（返回操作系统特定的错误代码，该错误代码仅与windows上的SocketError枚举匹配）
- socketerrorcode（将错误代码再次映射到windows错误代码，以便可以根据SocketError枚举检查错误代码）
-
我正在实现一个UNIX域套接字进程间通信代码，在试图从套接字读取时，我随机地碰到了这个错误--“errno 11：资源暂时不可用”。我使用MSG_PEEK从套接字读取字节数，并为接收缓冲区分配字节数，并读取实际数据。 套接字是一个阻塞套接字，我没有任何非阻塞的代码（总之，接受/读/写）。在阻塞套接字读取中，有什么可能导致这种情况的指针吗？在MSG_PEEK的手册页中，当socket标记为非阻塞时，
-
假定套接字处于阻塞模式
-
问题内容： 我想创建一个非阻塞连接。像这样： 为此，我使用了另一个线程，无限循环和Linux epoll。像这样（伪代码）： 如果我先运行服务器，然后运行客户端，那么一切正常。如果我先运行客户端，请稍等一会儿，再运行服务器，然后客户端将无法连接。 我究竟做错了什么？也许可以做不同的事情？ 问题答案： 您应该使用以下步骤进行异步连接： 用创建套接字 开始与 如果返回值既不是也不是，则中止并返回错误
-
创建套接字 使其非阻塞 呼叫连接 按预期返回-1和errno EINPROGRESS 调用select 返回>0，因此已建立连接 再次阻塞套接字 此部件的代码如下： 那还行。但是我有一个循环，在这个循环中我调用了一个函数，该函数检查是否收到了要读取的新数据包：
-
问题内容： 当我直接使用（没有诸如Scanner之类的界面）接收数据时，它不会阻塞。但是，当我尝试使用Scanner时（类似于我们从接收字符串的方式），它确实可以。我想知道这样做的原因，以及所连接的Socket提供给您的InputStream与in的不同之处。 用于测试的客户端（用于两个服务器） 挂起的代码： 不阻塞的代码： 问题答案： （我认为您已经知道了这一点，但是…） 该方法返回当前行的其余
-
问题内容： 为什么有人会喜欢阻止写而不是非阻止写？我的理解是，仅当您想确保写方法返回后，另一端获得了TCP数据包时，才希望阻止写操作，但是我什至不知道这是可能的。您将必须刷新，而刷新则必须刷新 底层操作系统的写套接字缓冲区 。那么，无阻塞套接字写是否有任何缺点？就性能而言，拥有较大的底层写套接字是否会缓冲一个不好的主意？我的理解是，底层套接字写缓冲区越小，当底层套接字缓冲区已满且isWritabl