Il 01/08/2014 23:46, Sergio R. Caprile ha scritto: > 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. 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. 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. > 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. 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. > 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). 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 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. 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. 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. > 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 ? 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. 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. > 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 suppose that I found something like a bug because all other examples (also netio) work well with no problems. 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
>
logo
*
Massimo Manca*/, Micron Engineering/
via della Ferriera, 48 33170 Pordenone PN ITALIA
Tel: 39 0434 1856131| Mobile: 39 349 4504979
www.micronengineering.it
Twitter
<http://s.wisestamp.com/links?url=https%3A%2F%2Ftwitter.com%2Fmassimomanca>
LinkedIn
<http://s.wisestamp.com/links?url=http%3A%2F%2Fit.linkedin.com%2Fpub%2Fmassimo-manca%2F7%2Fa15%2F479%2F>
SlideShare
<http://s.wisestamp.com/links?url=http%3A%2F%2Fwww.slideshare.net%2Fmicronpn>
Contact me: Skype micron.engineering
Designed with WiseStamp -
<http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3Daaa0e17b0c4ca423%26v%3D3.13.31%26t%3D1406929657462%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10>Get
yours
<http://s.wisestamp.com/links?url=http%3A%2F%2Fr1.wisestamp.com%2Fr%2Flanding%3Fu%3Daaa0e17b0c4ca423%26v%3D3.13.31%26t%3D1406929657462%26promo%3D10%26dest%3Dhttp%253A%252F%252Fwww.wisestamp.com%252Femail-install%253Futm_source%253Dextension%2526utm_medium%253Demail%2526utm_campaign%253Dpromo_10>
---
Questa e-mail è priva di virus e malware perché è attiva la protezione avast!
Antivirus.
http://www.avast.com
<<attachment: m_manca.vcf>>
_______________________________________________ lwip-users mailing list lwip-users@nongnu.org https://lists.nongnu.org/mailman/listinfo/lwip-users
