Hi
TCP_DEF_MTU is sent in each TCP frame to signal the size of the receivers open window. Being a fixed value it will allow the other end to send TCP data until the windows closes - which it will never actually do. When this value is set to a larger value then, the other side can send larger packets but it doesn' mean that it will - it may also be limited during transmission to another value MSS (maximum segment size) which is an option during the connection handshake (SYN).
OpenTCP doesn't support the MSS option nor Windowing as such. Perhaps the segment size if being limited somewhere else in the network or simply by the application at the other end being too slow to collect a larger buffer full of data before it wants to send the next segment - so never utilising the available segment/window size capability.
If you capture a sequence using Ethereal and send it to my Email address I can maybe tell you exactly what is happening.
You may also like to look at the uTasker Operating system with integrated tcp/ip stack for the HCS12. See live demo via web cam at http://212.254.22.36:8080 - log on and control a device using Browser at http://212.254.22.36 (user "ADMIN" password "AL6000S")
A demo project is available at:
http://www.mjbc.ch/software/Demo/j8jdwk-ku7/uTaskerPingDemo.zip
which allows a simulated NE64 to run on the PC in real-time; inclusive Ethernet interface. Ping the simulated device from the local PC or another on the network, see the frames pass through the real NE64 interrupt routines, up the stack...etc.
The uTasker is free to educational establishments and for non-commercial use, including free email support.
Regards
Mark Butcher
www.mjbc.ch
Hi
I assume that you are using the NE64 with 8k SRAM. It's a great little device for a number of interesting jobs. (with extended memory the Ethernet interface only works at 10M and so I have stuck with the 80 pin part until now)
However the 8k SRAM also means that it requires tight utilisation of resources. For more powerful jobs the Coldfire is the best choice - the NE64 still remains the best choice for all others 'small' applications.
I tend to keep with small buffer sizes so as to get the most out of the application. This is at the expense of IP efficiency but this is often not a killer. If you want to get data from a remote sensor it is often not a big deal if it arrives chopped up into smaller frames rather than less frames of maximum size - it is still good to be able to get if over the Internet from a single chip and quite power consumption device.
TCP applications are no problem in this respect. Only DHCP is a bit of a nuicance since it requires 1k buffers to be used to ensure that the BOOTP UDP frames really fit, sacrificing 1k which the application could well use. Note that although all the rx and tx buffers have to be the same size, it is not necessary to use all of the tx buffer (the amount of it used is under your control) and so I tend to start variables in the middle of it if I know that I will not utilise it all.
If you are doing an application which receives TCP frames to be sent to a lower speed interface (classically the serial interface using XOFF/CTS protocol) then the lack of windowing support in the OpenTCP implementation becomes a problem. The reason is that there is no flow control mechanism across the network and TCP frames will invariably arrive at a rate much faster that the data can be sent over the interface - in this case the window advertised by the tcp stack will tend to equal the window available in the serial output buffer which must close in order to choke the data - if not it will be lost. Reception TCP frames can also be simply ignored (dropped) if there is no room but this results in ugly repetitions and is inefficient due to the repetition timeout delays.
It's interesting stuff and sometimes quite challenging finding the best compromise.
Cheers
Mark Butcher
www.mjbc.ch