i tried out the TCP send timeout function of the W6100. From reading the datasheet i thought, that SENDOK only occurs, if no timeout occurs.
But reading the SN_IF register, i found out, that the SENDOK flag sets, although the cable is unplugged.
After the timeout time, also the TIMEOUT flag sets.
QUESTION 1: Does SENDOK appear independent from a timeout?
QUESTION2: Assuming i would send a TCP packet over the internet, when a packet gets lost and meanwhile i send another 20 packets (because the SENDOK flag tells me, everything is OK) - how would i know, from which packet sent this TIMEOUT comes? And more irritating to me is, that if a timeout occurs, the socket automatically closes, but if i unplug the cable or loose LINK all sockets remain established?
Did i miss something here?
Blockzitat /* wait until SEND or SEND6 Command is completed or Timeout is occurred */
while(Sn_IR[SENDOK] == ‘0’ and Sn_IR[TIMEOUT] = ‘0’); <<< it should be "=="
Only one explanation: it can not sense unplugged cable on the TX line, and just sends into nowhere. Therefore conclusion - if you cut RX lines and socket was setup before, you still can send some data until socket breaks / times out.
I suspect timeout occurs because W6100 does not receive ACK to the packet sent. It will of course not receive because cable is unplugged.
See something good in bad. If your cable was unplugged by mistake, you have some time to reconnect it and continue data transfer.
I suspect while you get SENDOK, the TX buffer pointers are not being internally shifted until socket receives ACK for the data sent. In other words - you can send data of maximum size of TX buffer, and W6100 will give you no free space in TX buffers until it receives ACK for some data and frees space for your further data.
You know, that the W6100 has the capability to sense that? Why you have the flag for this? Of you can sense such things: a plugged cable with open end means reflection, increased capacitance and so on…
Of course it does…read the datasheet - thats a “TCP-thing”.
Imagine one guy plugging out a cable by purpose and plugging it into another peer imitating the one connected before - don’t say - no one would do that, then you don’t believe, there are thiefs and hackers.
You are right, I tried it out today: the buffer is not freed until data is send out successfully or a timeout occurs (a timeout if force a socket close - therefore “frees” the buffer).
But i kind of makes TCP useless here, because i don’t have any information about which data packet got lost here. If you send two packets each 512 bytes, how you now, which of these packets got lost? It really make no sense to data transmission logic - 5 packets arrive, ones missing? Which one you’d never know.
I hope wiznet is going to implement a limited packet tracking. That, if you send out one packet, you have can read the TCP sequence number of that packet and the timeout should tell you which sequence number got lost - so you don’t have to do complicated selfimplementing with self handshaking inside a TCP packet or calculating the bufferpointers and remember them - then you could just switch to UDP and implement your own TCP - which would make the wizchip kind of useless here.
And again - it really makes NO sense to close a socket, when a ACK timeout occurs - the user doesn’t have any chance here to resend the packet or analyse the error.
But NOT closing all sockets, when the cable is unplugged really is an security issue.
I think it can sense connection to the transformer (resistance/capacitance, as you said), but can not sense connection after the transformer, at least reliably.
Not me, W6100.
Why not? For debugging purposes? Probably it is useful for some implementations, but not for those publicly shared.
Having physical access to device is a serious advantage, and there may be no difference if you have W6100 or i219 controller.
You do not need to. TCP handles the session. You just push data when space allows. If something fails, you get to restart - from the beginning, or through additionally defined protocol informing you what data receiver actually received in previous session.
WIZnet chips’ purpose is highest level programming possible (with some low level mechanisms). You can use W6100 in MACRAW mode making your own TCP/IP implementation receiving raw data and then you have full control over the packets. But in usual life you want simpler things, because complex things are already there and cost much more including proprietary firmware (e.g. networking cards).
User opens connection and sends/receives data. If it fails, user restarts. This is no probem is you send several packets, of course if you send 1GB file you need to design some mechanism to restart at the point when it failed, but this mechanism is above TCP/IP level.
This unplugging of the cable bears absolute the same risks as having man-in-the-middle scenarios, but in addition, it requires physical access to the device.
