Thank you very much Guy and Ian. I understood everything you said. So...nor my OS (windows) or the remote system have knowledge about speed limits on the ethernet devices? So, even for Windows, to send data correctly (since it knows nothing about my cable modem) it has to use TCP. Other protocols have no reliability at all - unless they use tcp-like protocol? So packets like ARP will be sent twice if no reply has been recevied after a certain period?
I have this case scenario... Say, I send UDP packets at 10mbit. The remote system is 100mbit and able to send me replies in <50ms time. Say, my cable is limited at 128kbits. So, I will reach my limit pretty quick. Does this mean that I will have to send a certain amount of data twice since it was dropped by the cable system? Is that how windows operates? Thanks, Daniel ----- Original Message ----- From: "Ian Schorr" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, July 14, 2003 11:43 PM Subject: Re: [WinPcap-users] Sends too fast? > > On Monday, July 14, 2003, at 05:55 PM, Daniel Frimerman wrote: > > > The cable modem is plugged into a 10mbit ethernet card. > > Putting throttling will do, but isn't it strange that I'm capped at a > > certain speed, yet I can send out 10mbit? > > This isn't strange at all, since your ethernet card/protocol stack has > no concept that your cable modem is capped at a certain rate. There's > no "signal" from the cable modem to tell your system that it is rate > limited, or that you're sending more data than it can pass on (I have > yet to see a cable modem that supports any kind of Ethernet flow > control, and you're using 10mbps Ethernet, anyway). > > Instead, packets are flooded out the interface as fast as they can. > Presumably, your application writes data to the socket, which passes > the data to IP, which passes it down to hardware (and yes, I'm > simplifying this a bit)... If your app is writing data at or faster > than 10mbps and doesn't stop, and the transport accepts the data and > passes it down and doesn't stop (i.e. TCP isn't waiting for an > acknowledgement), the NIC should receive this data at a high rate and > send it as fast as it can, without stopping. This data eventually > begins "pooling" at the point where the rate conversion occurs (from > 10mbps to, say, 256Kbps), and most likely begins overflowing buffers in > whatever is doing the rate conversion, which results in the packet loss. > > > Anyone else has the same problem as I do? > > Yes, anyone doing the same thing you are. > > > > >> Use a protocol that does flow control, such as TCP, or put your own > >> throttling into the sending loop. > > > > Doesn't this mean that if I create a UDP socket and send it as fast as > > possible it would reach ~10mbit, since UDP has no flow control? > > Absolutely. Very possible, and seems like that's what's happening to > you. > > > > > I thought cable modem caps were physically on the cable modem itself > > which I > > thought would block the packets until speed is synchronized :( > > Even if the data rate is capped on the cable modem, your system still > has to somehow KNOW that it should slow down, or that it should stop > sending data to avoid overflowing buffers. There's no magic there. > > In your example it sounds like there is no "end-to-end" flow control > present - no layer 2 flow control, no layer 4 flow control (i.e. TCP), > and no application layer flow control (your app has no signaling of any > kind, it simply generates bursts of data). You send data to some > device on the network faster than it can send out. Data gets buffered, > and those buffers (eventually) overflow. In short, you need some sort > of flow control along the network path to prevent data from getting > dropped. > > Incidentally, it's very possible that the cable modem itself isn't > limiting your sending rate, but the rate limiting is happening farther > back toward your cable provider. But it doesn't really matter much for > your problem. > > > If I send too fast, above my cap limit, does it mean I packets? If > > yes, I > > can't rely on their arrival can I? > > If you send faster than some device along the path can handle, and you > have no mechanism to slow or stop you, then yes, you will eventually > lose packets. > > Think about it this way - let's say that you sent data at 100mbps to > your cable modem, and it was able to forward on to the cable provider > at 100mbps as well. The cable provider can even send your data to the > Internet at 100mbps, and so on, until it finally gets to where you're > going - another PC with a *10*mbps Ethernet card. If the 2nd PC is > plugged into a switch, the switch might be able to buffer a little bit > of the 100mbps data that it's trying to squeeze down the 10mbps pipe, > but if you keep sending data at 100mbps, the switch eventually won't be > able to hold anymore. Now, in this case, how does YOUR system know > that it needs to slow down? It's the same basic situation, we've just > moved the "point of congestion" farther down the network path. > > And you, as an app writer, can NEVER "rely" on packets arriving without > some sort of mechanism for data acknowledgment, whether that be a > reliable transport (like TCP), some kind of mechanism built into your > application, etc. > > Ian > > > > ================================================================== > This is the WinPcap users list. It is archived at > http://www.mail-archive.com/[EMAIL PROTECTED]/ > > To unsubscribe use > mailto: [EMAIL PROTECTED] > ================================================================== > ================================================================== This is the WinPcap users list. It is archived at http://www.mail-archive.com/[EMAIL PROTECTED]/ To unsubscribe use mailto: [EMAIL PROTECTED] ==================================================================
