我正在为不支持全双工模式的 PHY 媒体开发自定义网络驱动程序。
我想在这个网络驱动程序和这个半双工 PHY 媒体之上使用 TCP/IP 流量。但是 TCP/IP 流量可以是全双工的。我想在这个驱动程序中实现一些机制/算法,以便这个自定义网络驱动程序将 TCP/IP 流量转换为 linux 中的半双工。
请让我知道这是否可以实现或如何实现。
我正在为不支持全双工模式的 PHY 媒体开发自定义网络驱动程序。
我想在这个网络驱动程序和这个半双工 PHY 媒体之上使用 TCP/IP 流量。但是 TCP/IP 流量可以是全双工的。我想在这个驱动程序中实现一些机制/算法,以便这个自定义网络驱动程序将 TCP/IP 流量转换为 linux 中的半双工。
请让我知道这是否可以实现或如何实现。
因此,您正在尝试在实际上不支持该功能的卡上编写支持全双工流量的驱动程序...
嗯..你必须知道网络子系统是内核中最大的子系统之一,也是少数几个实际使用软中断的子系统之一(因为它总是在考虑在这个多处理器时代适当地扩展)并且仍然有诉诸一些诡计(NAPI)来管理由当今媒体不断增加的速率产生的大量中断请求......为什么我说这一切是因为我只是想提醒你现实生活的复杂性涉及编写“常规”网络驱动程序,更不用说“伪全双工”驱动程序了。
现在我相信您非常想要的是给... TCP/IP 堆栈(是吗?客户端,无论是 MAC 层还是诸如 ethtool 之类的东西)都可以像使用“常规全双工”驱动程序(并期望结果)一样使用它(在转储和检索数据包方面) ...
所以如果真的是这样的话,我想知道给出这样的错觉有什么好处呢?也许你只是在做实验?在任何情况下,默认情况下 TCP 无论如何都是全双工的,并且通过使用半双工媒体,数据速率无论如何都比使用全双工适配器获得的数据速率低一点(尽管不完全是一半)。我认为在高层(就功能而言)媒体是全双工还是半双工(MAC 层除外?)如果我错了,请纠正我。
当前使用(并且仍然)相当多的半双工媒体,因此有许多媒体同时支持全双工和半双工流量。我看不出它将如何影响驱动程序的客户端(除了降低总体数据速率是唯一有形的影响)...这意味着您几乎可以查看内核中的任何网络驱动程序,并看到它有办法将适配器配置为使用全双工或半双工(以及用户空间可以说 ethtool 作为切换它的方法之一......)......
无论如何,您可能想看看这里的MODBus 驱动程序(默认情况下为半双工总线)并从中获得一些提示。
我不确定您如何将 MAC 层与 TCP 层联系起来。双工模式是一个以太网域,它不会传播到 IP,也不会传播到 TCP,在以太网术语中,双工意味着您可以在不同时间(半双工)或同时(全双工)专门发送或接收 MAC 帧.
网络堆栈的上层完全(至少他们应该)不知道这个过程。考虑以下示例,您正在使用 FTP 通过网络发送一个巨大的文件,假设大多数正常的网络系统堆栈是 FTP/TCP/IP/以太网。从 FTP 的角度来看,您有一个虚拟会话,从 TCP 的角度来看,您有一个虚拟管道,从 IP 的角度来看,您只知道如何到达终端系统,从以太网的角度来看,您只知道如何到达网络中的下一个节点。
TCP 不关心您的数据包在传输过程中是否被切碎,也不关心您的数据包是否由于传入数据包到达而延迟在某个阈值内它只关心接收数据包到达最终目的地的确认回执。我希望我能表明我的观点。