Talk:UIP (software)

On 2 July 2023, it was proposed that this article be moved from UIP (micro IP) to uIP (software). The result of the discussion was moved.

Compliance[edit]

Despite the claims in the article uIP is not fully compliant with RFC1122 as it cannot leap tall buildings at a single bound. 86.11.47.92 (talk) 22:10, 17 February 2016 (UTC)[reply]

Dubious-discuss annotation for uIP responding too fast for a PC[edit]

I think this is factual, but I must respond with personal experience. In 2012 I personally ported uIP0.9 to an ARM Cortex M0 running at 20mHz, using an on-board DMA ethernet. The response time was under 100us, (it varied from 15us to 90us, depending on what the event loop was doing, and what the packets contained). My monitoring PC, running Windows 7, could not "see" the first packet from uIP, either on packet-sniffing software (Wireshark), web browser, or even a ping utility. The PC was a quad-core pentium running at 3.5 GHz. It was old, but never seemed especially slow to me. The packet was clearly visible on an o-scope, so I have no doubt that it was sent. That's how I got the timing. I added a 1 millisecond looping delay to the uIP driver, and then it worked, but the event loop was slower. I ended up restoring the "send it twice" code that was in the standard distribution. This worked; The send it twice code just reset the DMA pointers, so the event loop was pretty fast. The fact that the delay enabled the PC to receive the first packet indicates to me that it was the PC's problem. Ray Van De Walker (talk) 23:52, 12 March 2019 (UTC)[reply]

There are two problems with this. One is the question how important or representative the observation is. The other is a logic problem. Consider this: if you would set up the Windows machine to listen on UDP to an asynchronous stream of packets, it will receive packets from the device irrespective of whether it's an answer to a packet from the Windows machine or when it comes. The answer could even precede the request ;-). Now, if your Windows TCP/IP stack or your program has a race condition that allows you to send packets before you're able to receive them, that's another matter, but it has nothing to do with uIP as such. You just found a bug in the combination of Windows and your Windows program. (Emile van Bergen). — Preceding unsigned comment added by 88.206.136.220 (talk) 11:55, 8 December 2020 (UTC)[reply]

Dates[edit]

when talking about things like "was an Open Source ..." and "Later versions of uIP..." it would be helpful if some dates were included. — Preceding unsigned comment added by 203.206.162.148 (talk) 01:39, 27 August 2014 (UTC)[reply]

Requested move 2 July 2023[edit]

The following is a closed discussion of a requested move. Please do not modify it. Subsequent comments should be made in a new section on the talk page. Editors desiring to contest the closing decision should consider a move review after discussing it on the closer's talk page. No further edits should be made to this discussion.

The result of the move request was: moved. (closed by non-admin page mover) – Material Works 16:52, 10 July 2023 (UTC)[reply]

UIP (micro IP) → UIP (software) – Standard disambiguation format * Pppery * _{it has begun...} 13:02, 2 July 2023 (UTC)[reply]

The discussion above is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.