[EMAIL PROTECTED] wrote on 10-10-2005 11:34:25: > I already posted lot of questions to this group regarding > my tftp client implementation of lwip , but I did not get any > replies .I also posted my source code implementation , but the same.
Posting code doesn't make the coders actually look at it, most of us dislike that. If you want implementation support you should be more specific than 'it doesn't work' and describe the problem in text please. > I hope you can guide me with my probelm this time . As I said I am > writing a tftp client application on lwip using the socket API , > tapif interface (using bridge configuration ) on Redhat linux 2.4. > 20-8 . I need to put and get files from/ to a remote server. But > both put and get are not working.While getting I am only getting > first 512 bytes and then tapif_input function halts Ah this is better, As far as I can remember the TFTP protocol uses a state-machine. Can you tell us in which state the server is? And can you make the state transitions visible? Tapif_input will repeatedly be called for the incoming TFTP datagrams, most likely causing server state changes. > I am creating > only 1 thread in my application and I guess this is making problems Please do not guess, do you know whats actually going on in the code? If there are multiple threads in the design you shouldn't remove or disable them. What are these threads for? > , How can I use thread mechanism safely in my application ??? I am > herewith attaching my implementation to this email , please have a > look and suggest me in this ...Help!!!!!!! > > > Also one more thing is I profile my whole stack using gprof > /Functioncheck (profiling tools on linux ) as a part of my work , > these tools are giving erroneous(wrong) results for example > sys_arch_sem_wait is called 744 times , sys_sem_signal is called 699 > times ...and so on.... do u guys really think that these functions > are called this many number of times.... I run my application and > then run the tool , so it is a dynamic execution profiler.....I > guess there is a problem with my thread implementation.... Ah, do not use gprof. For another project a colluege of mine crippled some code by adding profiling flags to a Makefile. It took me a week to find the root-cause. Sorry, I'm not going to look at your code for now. Christiaan Simons Hardware / Software Engineer Axon Digital Design +31 (0)13 511 66 66 +31 (0)13 511 41 51 [EMAIL PROTECTED] http://www.axon.tv This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify the system manager. This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. _______________________________________________ lwip-users mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/lwip-users
