Re:Re: [lwip-users] Is something wrong in netconn_accetp() api ??

[yihect]

 

 Thanks Jonathan.

 

 You are right, the HTTP request package is divided into several IP Frames due to 128_byte mss of machine side. The http server start to send his reply on recving the first frame. It seems to be the reason.

 

 I found TCP_MSS option is set 128 in opt.h. To let the mss be greater, I set it to 512, but it is useless. so, how to extend the mss size of my machine by setting these options?

 

 On the other hand, can I put the netconn_recv() api into a while circle to get all frames of the same request package? Is there some sample code for this?

 

 

 

 

在2008-08-21，"Jonathan Larmour" <address@hidden> 写道：
>yihect wrote:
>>  Hi, Jonathan, thanks a lot for your reply.
>>  
>>  The netconn_recv() can return none-zero netbuf ptr now. But the http
>> demo can't work yet.
>>  
>>  Debugging network program seems tool difficult. The client tool, IE in
>> my windows, will send several ethernet frames to my bf531 box
>> continuously. That makes me difficult to debug, because several network
>> chip interrupts raise up, and the program will goes here and there in
>> multi_tasks environment like uCOS.. oh, that makes headache to me.
>>   So, my question is: is there some simple tools for protocol stack
>> debugging?
>
>lwIP comes with many options you can set in lwipopts.h to control debug output.
>
>> To be an example, is there one tool, by which we can send a
>> package or frame one time manually?
>
>Not really. TCP has well-defined real-time constraints and timeouts. The
>most you can do to split things up is to tweak your driver temporarily
>(just while debugging) to not allow through only one packet at a time, e.g.
>by masking the interrupt (which you can then unmask in your debugger when
>you're ready to get another packet). But you can expect connections to time
>out in your clients while doing this of course, and be faced with extra
>traffic because of retransmissions, thus changing the traffic pattern.
>
>Rather than trace a packet through the stack in your case, I think it would
>be better to closely at the problem when you see the problem. So, what
>problem are you actually seeing now?
>
>You may need to pay attention to the stated assumption in the example
>server that data arrives in a single netbuf. You may want to check if
>that's why things are going wrong for you now.
>
>Jifl
>
>> 在2008-08-20，"Jonathan Larmour" 
>> 
>> 
>> ------------------------------------------------------------------------
>> 
>> _______________________________________________
>> lwip-users mailing list
>> address@hidden
>> http://lists.nongnu.org/mailman/listinfo/lwip-users
>
>
>-- 
>eCosCentric Limited      http://www.eCosCentric.com/     The eCos experts
>Barnwell House, Barnwell Drive, Cambridge, UK.       Tel: +44 1223 245571
>Registered in England and Wales: Reg No 4422071.
>------["Si fractum non sit, noli id reficere"]------       Opinions==mine
>
>
>_______________________________________________
>lwip-users mailing list
>address@hidden
>http://lists.nongnu.org/mailman/listinfo/lwip-users

---

22元超值饭面,8.5折纯珍比萨,必胜宅急送网上点餐优惠多