Hi Simon, Thanks for the prompt response!
I'll try to clarify. I'm testing the stack as much as I can before integrating to my final setup: Currently, I have 2 processes, each has an lwip's PPPoS stack, and on top of that using lwips socket api to create a tcp socket. PPPoS read write methods in each process, is write/read to a local host, Android tcp stack, opened socket(which eventually be replaced by rfcomm). I'm manually introducing losses to the physicak layer(ppos write method on each process), and expecting lwip's stack to keep on top of its tcp socket. What do you mean prepared for re-transmissions? I rely lwip to handle that. On Tue, Nov 7, 2017 at 11:25 PM, [email protected] <[email protected]> wrote: > Itzik Levi wrote: > > I'll recap the setup: > > 1. Non blocking sockets. > 2. poll(thread 1). > > > OK, poll is pretty new. There might be problems of course, as it's new > code and also select has change a bit due to adding poll support. > > > 1. read/write in 2 different threads, but not in parallel, mutex > protected. > 2. poll may occur in parallel to read/write. > > > But the original problem, as described, is the matter of tcp stream > corruption. > > > I still don't get your test setup. You said the final thing is PPPoS, but > you're having tcp streams for now? Is your test prepared for > retransmissions? Because these are expected if you drop TX bytes! > > Simon > > _______________________________________________ > lwip-users mailing list > [email protected] > https://lists.nongnu.org/mailman/listinfo/lwip-users >
_______________________________________________ lwip-users mailing list [email protected] https://lists.nongnu.org/mailman/listinfo/lwip-users
