App_Simple_Webserver 1v3

Non-technical related questions should go here.
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Re: App_Simple_Webserver 1v3

Postby Folknology » Fri Sep 10, 2010 12:00 pm

I think because httpd.c in the webserver example is so simple it processes the httpd_recv (incl http_parse) so quickly that it asks for the next tcp event before UIP is ready. I sometimes see it were the timing is borderline and it succeeds and sometimes doesn't, I think the delay provides a big enough window to guarantees success.

Another thought, maybe we are hitting issues with the PT Threads
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm

Postby russf » Mon Oct 25, 2010 8:20 pm

I was slow to find Folknology's work on this topic. Here I am, 11 months later hitting the same issues. When I remove prints from my otherwise (mostly) functional client, I can't send a single packet.

How can we improve this?

Has anyone made any progress?

--r
User avatar
leon_heller
XCore Expert
Posts: 546
Joined: Thu Dec 10, 2009 10:41 pm
Location: St. Leonards-on-Sea, E. Sussex, UK.

Postby leon_heller » Mon Oct 25, 2010 8:55 pm

I get the same run-time errors with App_Simple_Webserver 1v3 that I get with the XC-2 demo software:

NFO: Ethernet Rx Server init..
INFO: Ethernet Rx Server started..
Using static ip
dhcp_init
uIP log message: ip: invalid version or header length.
uIP log message: ip: invalid version or header length.
uIP log message: ip: invalid version or header length.

That's with the 10.4.2 tools under Win7 x64.
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm

Postby russf » Tue Oct 26, 2010 5:18 am

To me, it seems like a bug that a connection listening on port 80 needs to filter out other ports. Only getting traffic for the port you are listening to is the whole point of listening on a specific port.

I too am having very mixed results with a TCP/IP client that is intended to send data to a remote server. I'm going to try your filtering trick to see if that brings anything.

IN my current code, the client blocks at random times. Without a bunch of printstrs, I can hardly get anything out at all.

I'd love to hear if you cleared up these issues, and how.

Best,

-r
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm

Postby russf » Tue Oct 26, 2010 5:27 am

Does XMOS document the test rig used for testing the XTCP stack?

I think it would be important to know what other traffic is on the network. When I plug my XC2 into my MacBookPro, it is exposed to MDNS, Netbios, and several other kinds of traffic.

The results might be different if testing is done on a more sheltered network.

If XMOS tells us how XMOS tests, we can help spot why our environment has problems and while XMOS tests pass. This ties in to my recent posts related to Open-ness.

--r
User avatar
Berni
Respected Member
Posts: 363
Joined: Thu Dec 10, 2009 10:17 pm

Postby Berni » Tue Oct 26, 2010 6:03 am

Well actually the locking up could be a uIP port issue. Since when i wrote my own webserver i had locking up issues. So i spent days trying to find the problem until i tried the same on the original webserver code and found out i can crash it the same way.

I found out a sure way to crash it is in firefox you hit refresh like mad and after some time it will lock up until you reset it.The old lwIP code does not seam to do that.

It might be a problem with the number of connections piling up and not closing altho i haven't went in to trying to find the problem inside uIP as its quite a lot of code.
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm

Postby russf » Tue Oct 26, 2010 6:14 am

Yes, Berni, you are right, this could be a uIP issue.

You previously pointed out that the layers on top were suspect. I see the value in the XC layer which should simplify having clients on different cores, so I'm giving it a spin.

We should look at this code as Alpha quality, until proven otherwise.

--r
User avatar
russf
XCore Addict
Posts: 146
Joined: Thu Dec 10, 2009 10:17 pm

Postby russf » Tue Oct 26, 2010 6:47 am

I need to see a test-suite for this stack.

Who is interested in working with me to build one?

Over on another thread, I'm talking about open source cooperation, and this is the perfect topic for it. The main question is who has time and interest, and whether XMOS will be involved.

Can we kick this idea around a bit? I'm thinking of a virtual sprint, where we use skype and github to work together.

Outcome..
A set of MINIMAL tests on top of the XTCP stack. These should demonstrate correct usage and provide a reference for future testing.

We want to be able to keep up to date with uIP improvements, and to pick up any Ethernet fixes, so we should keep to the published XTCP interface if we can.

A tracker listing failures of the tests, and fixes if forthcoming.

We should do all this from a well-known starting point, with respect to XMOS code, so that XMOS can easily
merge approved changes.

Requirements...
I want fast and reliable transfer of data to a remote server.
Also I need occasional queries to another remote system.
Others will want reliable data transfer to the XC-2
I'm looking for a starting point of 5Mbit/sec. Is that feasible? Should be!

Testing needs...

XC-2
nearby system with free ethernet port (OSX is cool, linux too. Windows... hmmmm!)
Wireshark

--r.
User avatar
leon_heller
XCore Expert
Posts: 546
Joined: Thu Dec 10, 2009 10:41 pm
Location: St. Leonards-on-Sea, E. Sussex, UK.

Postby leon_heller » Tue Oct 26, 2010 11:12 am

Has anyone had the same problem with App_Simple_Webserver 1v3 that I mentioned in my post, earlier?
User avatar
Folknology
XCore Legend
Posts: 1274
Joined: Thu Dec 10, 2009 10:20 pm

Postby Folknology » Tue Oct 26, 2010 7:46 pm

Actually I gave up with the code base as is (xtcp etc..) I just could not get it to behave reliably, zero documentation was no help and no one seemed concerned that it wasn't working as it should. What's more because the source isn't in an open repository I am destined to trying to merge the next Zip/tarball that is lobbed over the wall when Xmos attempt to fix it and that could be the twelfth of never...

I am now pursuing an alternate strategy, will keep you guys updated, when I have something that works I will github it.

regards
Al
Last edited by Folknology on Tue Oct 26, 2010 8:01 pm, edited 1 time in total.

Who is online

Users browsing this forum: No registered users and 1 guest