Trying Nanode uIP get from remote socket example

[Paul Tanner]

Hi,

Now that I have it all installed OK I'm trying to write my own
example that connects to a given server/ socket and sends then
receives responses. This is structured exactly as per the hello world example.

Looking at this code in dhcp_status():

> Serial.println(buf); // our local IP address ex DHCP
> uip.query_name("www.greenend.org.uk");
> // Start the "hello world" app defined earlier, listening on port 1000
> uip_listen(HTONS(1000),hello_world_appcall);

I see that you are getting an IP for www.greenend.org.uk which later
gets printed but not otherwise used.
Then you listen to port 1000 on localhost

I looked in the headers for a call to connect to a given server/ port
but did not find anything.

So, in my example I guess I would not start listening until
resolv_found comes back with the IP of the server I want to connect
to. I'd call uip.set_ip_addr() passing the address just found and
then start listening on the desired port.

Does that sound right?

Initially I decided to hard code the IP of the server I want to talk to.

> uip.query_name("beta.pachube.com");
> // Start the "pach get" app defined earlier, listening on port 8081
> uip.set_ip_addr(173,203,109,233);
> uip_listen(HTONS(8081),pach_get_appcall);

This never gets a connection. Any ideas?

Also, I really need a much longer input buffer. I see that
TCP_APP_STATE_SIZE is set at max 150 bytes. Any reason not to
increase this to around 500?

Final point: when it does come back from the name lookup it does not
show the correct address. Not important if I am doing nothing with
it but strange nonetheless.

Regards, Paul

Paul Tanner - Virtual Technologies - http://www.virtual-techno.com
Tel: +44 1494 581979 Mob: +44 7973 223239 mailto:pa...@virtual-techno.com

[Stephen Early]

On Friday, 28 October 2011 11:42:19 UTC+1, paul_tanner wrote:

Hi,

Now that I have it all installed OK I'm trying to write my own
example that connects to a given server/ socket and sends then
receives responses.  This is structured exactly as per the hello world example.

Looking at this code in dhcp_status():

>     Serial.println(buf);  // our local IP address ex DHCP
>     uip.query_name("www.greenend.org.uk");
>     // Start the "hello world" app defined earlier, listening on port 1000
>     uip_listen(HTONS(1000),hello_world_appcall);

I see that you are getting an IP for www.greenend.org.uk which later
gets printed but not otherwise used.

Yes, that's just to demonstrate the resolver code!
 

Then you listen to port 1000 on localhost

I looked in the headers for a call to connect to a given server/ port
but did not find anything.

 The function you're looking for is:
struct uip_conn *
uip_connect(uip_ipaddr_t *ripaddr, u16_t rport, tcp_appcall_fn *app);

So, in my example I guess I would not start listening until
resolv_found comes back with the IP of the server I want to connect
to.  I'd call uip.set_ip_addr() passing the address just found and
then start listening on the desired port.

Does that sound right?

No.  uip.set_ip_addr() is setting the address of your Nanode.  You want to call uip_connect() instead.

Initially I decided to hard code the IP of the server I want to talk to.

>     uip.query_name("beta.pachube.com");
>     // Start the "pach get" app defined earlier, listening on port 8081
>     uip.set_ip_addr(173,203,109,233);
>     uip_listen(HTONS(8081),pach_get_appcall);

This never gets a connection.  Any ideas?

When the resolver returns the address for beta.pachube.com, call uip_connect() with the address, port number, and your appcall function.
 

Also, I really need a much longer input buffer.  I see that
TCP_APP_STATE_SIZE is set at max 150 bytes. Any reason not to
increase this to around 500?

The Nanode only has 2k RAM.  By default uIP is configured to support three TCP connections; each connection requires 30 bytes plus the application state size.  If you just increase TCP_APP_STATE_SIZE to 500, you'd need 1590 bytes of RAM just for TCP connections.  There's also a packet buffer of around 420 bytes (shared between all applications), plus the resolver cache, misc other state, and necessary things like the stack.

If you really need 500 bytes of connection state, you'll have to reduce the maximum number of TCP connections to 1.  This is the UIP_CONF_MAX_CONNECTIONS parameter in uip-conf.h
 

Final point: when it does come back from the name lookup it does not
show the correct address.  Not important if I am doing nothing with
it but strange nonetheless.

Odd - it really ought to!  What does it do if you run the hello_world sketch just with the name changed?  (I.e. is there anything else about your changed sketch that's stopping it from working properly?)

Steve

[Ken Boak]

Stephen, Paul,

 

Good to keep up with the latest devleopments in porting uIP.

 

Remember that there is an option of 32K x 8 external SRAM which can be used for buffering data.  This SRAM will be fitted to all boards after Christmas and so perhaps we should consider now how best to utilise it.

 

If you are around this weekend we may well get as far as the Pembury for beers on Saturday night

 

 

 

Ken

[Stephen Early]

Even without that, I probably ought to work on code that uses, say, 4k of the RAM inside the ethernet chip as extra buffer space.  It could "swap" the TCP application state into RAM before calling the application's appcall function, and then copy it back to the ethernet chip afterwards - then each TCP connection could have 450-500 bytes of application state instead of the 150 bytes it has at the moment.

I wonder if it's possible for me to add a sockets-like interface to uIP, and run the network stack off the timer interrupt?  That might be interesting, and easier for application programmers.  The SRAM could be used to buffer data for read() and write() calls.

What's happening on Saturday?  I need to go to the hackspace sometime (as long as I can get hold of a USB->serial converter) to use the vinyl cutter!

Steve

[Adrian Godwin]

I found a USB converter there yesterday (it was with the cables on the
stratasys) so I put it with the vinyl cutter. However, it seems to
have the wrong sex plug to suit the adapter cable (which is odd,
because I thought I made the adapter cable to suit a standard plug ..)

-adrian

[Ken Boak]

Stephen, Adrian

I am at Homecamp4 at C4CC  (16 Acton St, WC1X 9NG) for most of the weekend - from 07:30 tomorrow.

If you can't make HC4 - it would be good to meet up tomorrow evening to discuss uIP.  If you can make HC4 - come and talk to us all about porting uIP :)

BTW - I just ordered 4 of the Arduino USB-serial adaptor boards  - which look like a FTDI. They will be with me at C4CC tomorrow.


Ken

[Adrian Godwin]

Sorry, can't make it in this weekend. I may be at hackspace some time
next week (not Tuesday though), and I will try to get around to have a
go with Steve's port.

-adrian

[Stephen Early]

I've always had to use that cable with a F-F gender bender.  Perhaps I should replace the M connector with a F next time I use it?

Steve
(Who is now very off-topic!)

[Paul Tanner]

Thx Steve,

All is now resolved. Nanode is subscribing to a pachube datastream (just one so responses are under 250 bytes).  I did have to reduce the number of connections and increase the app state size of course.

When I took out the wrong assignment of the IP address the DNS lookup worked OK.

I also copied over my existing json decoder from MBED and it works OK.

I will this do something useful, tidy it up and post it somewhere shortly.
Tidying to include terminating nicely (say if the server closes the socket).

Help much appreciated ;-)

Regards, Paul

Paul Tanner - Virtual Technologies - http://www.virtual-techno.com

[Stephen Early]

Glad it's working!  I'm always happy to accept additional examples.

Steve

[Adrian Godwin]

The PROGMEM part is where he's got fixed things like the http header
in program memory rather than copying it into a ram buffer for
transmission. He's tweaked his application to make as much of the
actual ram available for buffers as possible. This is certainly
something worth doing on nanode apps, but he hasn't really found a way
of getting at previously unused memory.

-adrian

On Mon, Oct 31, 2011 at 6:49 AM, Winston Brummer
<winston...@gmail.com> wrote:
> Talking about examples. Has anyone ever read this article
> (http://www.instructables.com/id/A-Remotely-Programable-Relay-Controller-Christmas/).
> It also uses the AtMega328 but he seems to be able to get out bigger pages
> (980 bytes). Seems to be using something like PROGMEM, think its from
> EEPROM. I tried to follow his code but my grasp op the language seems
> lacking a lot.
>
> Winston