Il 01/08/2014 23:46, Sergio R. Caprile
ha scritto:
I mean a different thing. I said that also if I could send 3 packets calling 3 times tcp_write() there is no reason to send a message inside the sent callback because it could only resend the last message sent but.... if the callback is entered means that the packet was sent.Not really. tcp_write() allocates an internal pbuf itself, but you can only send 3 times in a row if yu have enough memory, and as TCP works, there is no concept of packet and no need to call 3 times in a row.
Of course sending only 1 message (I mean calling tcp_write() only 1 time) there is really no reason to provide the possibility to send hte same packet another time.
Yes, the problem is that for me the pcb is not freed. It contains valid data, exactly the last data sent and also the pbuf pointer is not null.You have a sndbuf and you can send as much as you can fit inside that sndbuf for that pcb. Once your buf is filled, you can only send again once data has been sent out, acknowledged by the receiver, and so that buffer freed, and that is signalled to you via the tcp_sent() callback.
I made a test running all night... it sent more then 200000 messages and received always the reply in a single message, same behavior for the messages sent.The whole point of calling echo_send() from inside the callback function is that in this case the total amount of data actually sent might not equal the amount of data received (in the whole pbuf).
If I correctly understand the code a tcp_write will try to put all data of a single tcp_write() in a single pcb also if I found some documentation saying that it could fit the message in more then 1 pcb so it will fit in a pcb chain.The first call to tcp_write() sends only the first pbuf in the pbuf chain, and once this is acked, the tcp_sent() callback will try to send the remaining pbufs in the chain.
May you know what is the maximum data size in a pcb? In my case I am sure it will fit always in a pcb because the message is shorter then 50 bytes.
Sure, the memory problem is that the tcp_write() pcb seems to be not deallocated and also its pointer is not null, so may be more a problem related to pbuf_free(). It is correctly called after tcp_write() so it frees the user pcb, then tcp_write() should copy the data in a new pcb that will be used by tcp_output() (and sent). The pcb that is not free is the pcb used by tcp_write to send the message, I shouldn't have any control on it.A pbuf may be a chain of pbufs, linked by p->next Either you have some memory problems or I've been lucky enough to get whole data inside a single pbuf and didn't trigger the possible bug. I recall sending small packets, what are you sending ?
My message is sprintf(szEchoMsg, "Raw message %d\n", iCount); and szEchoMsg is 50 bytes length.
The echo server triggers on \n so echoes line by line.
I suppose that I found something like a bug because all other examples (also netio) work well with no problems.Again, I suggest you use netio for big chunks of data. I don't have the time to build a short tcp_mss version of my linux port and try it, maybe on monday. I suggest you (besides going for netio) try with small messages, I'm sure those work OK. If they do, then check the pbuf chains, if they don't... check your port.
I started with tcp_echo raw example because until now I designed server applications using lwip but this time I have to write a tcp client application. Because it wasn't working I tried the ping example and it worked perfectly.
Take care that my mcu is working at 120MHz, my system tick is 1 ms and the timed functions are called every 250ms (I tryed also at 125ms with no difference).
Now my application seems to be working but I would test it with messages divided on several pcbs to be sure it really works well.
Also in my application I didn't provide to send pcbs inside the sent callback function.
Kind regards.
Regards
Massimo Manca, Micron Engineering via della Ferriera, 48 33170 Pordenone PN ITALIA Tel:
39 0434 1856131 | Mobile:
39 349 4504979
www.micronengineering.it |
Contact me:
|
|
Questa e-mail è priva di virus e malware perché è attiva la protezione avast! Antivirus . |
