As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Does anyone have especially good (or bad) experiences with any of the following embedded TCP / IP stacks?
uIP
lwIP
Bentham's TCP/IP Lean implementation
The TCP/IP stack from this book
My needs are for a solid, easy-to-port stack. Code size isn't terribly important, performance is relatively important, but ease of use & porting is very important.
The system will probably use an RTOS, that hasn't been decided, but in my experience most stacks can be used with or without an RTOS. Most likely the platform will be an ARM variant (ARM7 or CM3 in all likelihood).
Not too concerned about bolting the stack to the Ethernet driver, so that isn't a big priority in the selection.
I'm not terribly interested in extracting a stack out of an OS, such as Linux, RTEMS, etc.
I'm also not interested in commercial offerings such as Interniche, Micrium, etc...
The stack doesn't need all sorts of bells & whistles, doesn't need IPv6, and I don't need any stuff on top of it (web servers, FTP servers, etc..) In fact it's possible that I'll only use UDP, although I can envision a couple scenarios where TCP would be preferable.
Experiences with other stacks I've missed are of course also very much of interest.
Thanks for your time & input.
I've used both uIP and lwIP extensively.
uIP
Great if youre only wanting something basic like a bootloader
Small footprint.
Uses polling so we've never got over 3kbit with it :-(
No DHCP 'out of the box'
Poor UDP support
lwIP
Fully interrupt driven so much faster (~ x10)
Includes DHCP with failover AutoIP
UDP with multicast
Plus more
EDIT:
And we've never used either with an RTOS as there has never been a need.
+1 for lwIP.
We used this successfully on a project a few years back and found it to be generally very reliable. We found and fixed a few issues (generally corner cases within the TCP code) which we submitted back to the project, and even though the project has moved on quite a bit since then we didn't generally find it lacking in any features.
As you suspect it will work with or without an RTOS. It took about a week to get running on our system with an RTOS, which included changes we had to make to support an unusual DSP compiler. As you're probably using GCC on ARM you can avoid any of that effort.
It does contain many more features than you require, but if your requirements change a few years down the line then you'll be better off having started out with a more substantial stack.
lwIP
I worked on a project with a 3G modem where we needed a UDP/IP stack (no TCP) on top of PPP. We narrowed down to uIP and lwIP. We picked lwIP in the end because it had PPP already (uIP doesn't), and we had enough RAM to spare.
Our particular project didn't use an RTOS, and lwIP was fine to use without an RTOS.
I wasn't directly involved in porting the lwIP code, although I worked on the modem driver to interface with it. My impression was that the porting took a couple of weeks to get everything going smoothly, for our engineer who had previous TCP/IP experience. The lwIP code has been hacked by many people, and consequently has some rough edges (e.g. someone threw in a lone malloc() somewhere) but it worked for us after a little tweaking. We tested it with an independent validation suite.
In summary, it was "suitably functional" for our UDP/IP and PPP needs (but I can't comment on its TCP capabilities).
+1 for lwIP.
It is included in the Luminary Micros (now TI) Serial to Ethernet reference design with some added capabilities (some sort of "server side scripting" and cgi) working on bare metal (without RTOS).
It is rock solid and very performant with only 32KB or RAM.
Regards
PFM
I am pleased with lwip on the Stellaris Cortex-M3.
StellarisWare for the LM3S6965 eval board includes the enet_lwip demo. This is a small web server running over lwip which is running over bare metal -- no FreeRTOS in this case. The system is driven by the timer and Ethernet interrupts. It was pretty easy to rip out the web server and drop in my app. I did not have to become an lwip expert to get this running the first time.
Later I realized that my app was intrinsically up-call driven. At first, it had a sockets-to-upcall gasket. I replaced that layer with a much simpler one that translates lwip native upcalls to the app's upcalls, and optioned out lwip's socket API. This saved more flash and RAM space, and made the whole thing faster and simpler. With a little tweaking I got it running on the S2E board using 52K flash and 30K RAM.
You can try the open-source FNET TCP/IP stack.
I've used the Microchip TCP/IP stack. I've been very happy with it. It was very easy to implement, lots of demo code/tutorials available, and has support for a lot of protocols HTTP, tFTP, SMTP, SNTP, etc. A point that doesn't match your requirements however is that it is not easily portable to another architecture. In fact I think the license for the stack explicitly forbids this because Microchip wants you to run the stack only using their hardware the PIC18, PIC24, and PIC32. There is however an external Ethernet controller they sell that they will allow you to use certain portions of this stack with their ENC28J60.
I have used Interniche on FreeRTOS.
It's a full-fledged stack and supports quite a few features.
Since you are looking for a non-commercial version, my vote is on lwIP.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have just finished my course in data structures. and now i was thinking of building a bit torrent client.
However when i googled the stuff i couldn't understand any of the terminologies such as sockets, ports etc.
I just need a general guidance of where to look. Books, tutorials anything else in general what kind of skills do i need to make a bit torrent client, what kind of language is suited best for the job or even what kind of courses should i look to in order to accomplish my goal.
Thanks in advance for any help you can provide.
I would say one of the things you need to know is how computer networks work. This includes packet transmition, sockets, ports, threads, etc...
Computer networking is such a broad subject but I can leave here my personal sugestion of a book I loved to read and learn about computer networking (somewhat of an introduction to networking, but explains alot and even teaches you how to program in java using sockets).
Computer Networking, a Top-Down Approach Featuring the Internet, James F. Kurose, Keith W. Ross, 2005, Addison-Wesley
It explains concepts like packet transmition, threading, sockets, ports and so much more. I recall it even has a section about torrents.
Your question has two parts: Architecture and Programming. First you need to architect the program. Architecture is the process of visualizing a large "system" as subsytems, define interfaces between them and then writing a "tune" to which they can dance.
For the above system, these are those "Subsystems" :
Storage manager : Your torrent file is made of multiple chunks, which can be collected in any random order, assembled, verified and finally presented as a single file. Storage manager does this.
Transport Manager : This system understands how to transport torrent chunks in and out. Given a packet it sends or given host it receives.
Connection Manager: This system establishes connections to send and receive
etc etc.
Once you define the subsystems, then define what are the inputs and outputs. Then you develop each module.
Receiving recommendations for commercial TCP/IP stack implementation based on FreeBSD or NetBSD. Requirements are similar to a typical desktop PC running a browser, email and streaming voice/video. Which is to say a rich network functionality for a end-host type of device with mature implementation and reasonable performance.
BSD derived network stacks are deployed in wide variety of situations for years and hence have mature implementation.
It's supposed to run on a proprietary RTOS.
Most vendors I found don't advertise if their stack is based on BSD. Any recommendations?
-- Vineet
It's not commercial, but you could take a look at OSkit. It uses FreeBSD's networking stack. It might be easier to take the stack out of OSkit than from FreeBSD
http://www.cs.utah.edu/flux/oskit/
Closed. This question does not meet Stack Overflow guidelines. It is not currently accepting answers.
Questions asking us to recommend or find a tool, library or favorite off-site resource are off-topic for Stack Overflow as they tend to attract opinionated answers and spam. Instead, describe the problem and what has been done so far to solve it.
Closed 9 years ago.
Improve this question
I am searching for a tool that tests SIP calls. A platform that makes a call from SIP device A to SIP device B and reports results...
Any idea? A simulation platform would be ideal.
thnx,
cateof
There are many solutions. Some more broken than others. Here's a quick summary of what I've found while looking for a base for a proper automated testing solution.
SIPp
It's ok if you want only single dialog at a time. What doesn't work here is complex solutions where you need to synchronise 2 call legs, do registration, call and presence in the same scenario. If you go this way, you'll end up with running multiple sipp scenarios for each conversation element separately. Sipp also doesn't scale at all for media transfers. Even though it's multithreaded, something stops it from running concurrently - if you look at htop for example, you'll see that sipp never crosses the 100% line. Around 50 media calls it starts to cut audio and take all CPU of the machine.
It can sometimes lose track of what's happening, some packets which don't even belong to the call really, can fail the test. It's got some silly bugs like case-sensitive comparing of the headers.
SIPr/sipper
Ruby-based solution where you have to write your own scenarios in Ruby. It's got its own SIP stack and lots of tests. While it's generally good and handles a lot of complex scenarios nicely, its design is terrible. Bugs are hard to track and after a week I had >10 patches that I needed just to make it do basic stuff. Later I learned that some of the scenarios are just written in a different way, but SIPr developers were not really responsive and it took a lot of time to find it out. Synchronising actions of many agents if a hard problem, since they'd rather use an event-based, but still single-threaded version... it just makes you concentrate too much on "what order can this happen in and do I handle it correctly", rather than writing the actual test.
WinSIP
Commercial solution. Never tested it properly since the basic functionality is missing from the evaluation version and it's hard to spend that much money on something you're not sure works...
SipUnit
Java-based solution reusing Jain-SIP stack. It can do almost any scenario and is fairly good. It tries to make everything non-blocking / action based leading to the same problems SIPr has, but in this case it's trivial to make it parallel / threaded. It has its own share of bugs, so not everything works well in the vanilla package, but most of the stuff is patchable. The developers seem to be busy with other projects, so it's not updated for a long time. If you need transfers, presence, dialog-info, custom messages, RTP handling, etc. - you'll have to write your own modifications to support them. It is not good for performance testing.
If you're a Java-hater like me, it can be used in a simple way from Jython, JRuby or any other JVM language.
In the end, I chose SIPunit as the least broken/evil/unusable solution. It is by no means perfect, but... it works in most cases. If I was doing the project once again with all this knowledge, I'd probably reuse SIPp configurations and try to write my own, sane solution that uses proper threading - but that's at least a ½ year project for one person, to make it good enough for production.
Check out SIPp at SourceForge. It has many different scenarios for testing which the UAS mode (server) would probably be interesting for you and seems to allow INVITE, BYE, etc.
Try SIPInspector. It is a JAVA based utility to re-create different SIP signaling scenarios. It can play RTP and stress test your system too. Since written in JAVA it is highly portable and works on different oeprating systems. Way easier to user than SIPp.
What do you want to test apart from if the call gets through? Can't you simply call device B from device A and see if you can talk through the connection? If you want to have a look at the packets being sent you should look into wireshark.
I was trying to interface a 64 mb MicroSD card with MicroChip MCU. I sent cmd0-addr3-addr2-addr1-addr0-crc but didn't got any response.
What should I do next?
From the way you've phrased the question, it sounds like you don't have a very good understanding of how to communicate with external peripherals in general, on an embedded device. You should reference Microchip AN1169 which goes into detail on implementing SD card communication with an SD card. If that's not enough help, Microchip's application engineers are usually very helpful - don't rule out calling one.
On the other hand, if the application note is still over your head, you should strongly consider starting off with a less ambitious project - something like driving a motor or other simple IO that is not address-bound. The addressing issues can become very difficult when you already aren't familiar with embedded programming.
I stumbled on this thread because I was facing a similar problem. I know this thread is old but I want to post my experience here just for the record.
I have been doing FS and device programming for more than 8 yrs now so I am not a newbie :)
I was trying out PIC32MX and its inbuilt libraries for the first time and ran into the same problem as mentioned in the question. I double checked my connections after which I started doubting the library. I downloaded the latest versions for fixes but same behavior.
After lot of debugging for both hardware and software I found out that the microsd sockets contact for power was not sticking to the card contact at all! No power No response!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 4 years ago.
Improve this question
I have an existing standalone application which is going to be extended by a 3rd-party, using a network protocol. The capabilities are already implemented, all I need is to expose them to the outside.
Assuming the transport protocol is already chosen (UDP), are there any resources that will help me to design my application protocol?
There seems to be a lot of information about software design, but not on protocol design.
I've already looked at Application Protocol Design.
See Jabber protocols design guidelines and RFC 4101. Although it is aimed at making RFCs more easy to understand to reviewers, this RFC provides some interesting advices.
Have you looked at Google Protocol Buffer? It seems like a good way to resolve this issue.
You can create an endpoint that communicates with your existing app and then responds from 'outside' using the protobuffer protocol. It's binary, so it's tiny and fast and you don't have to write your own protocol manager, 'cause you can use the Google ones. The downside is that it has to be implemented on both sides of the system (on your 'server' side and on the consumer/client side).
Another recommendation for protocol buffers - nice tight binary with little effort. Note, however, that while the binary protocol is well defined, there isn't yet an agreed RPC standard (several are in progress, tending to lean towards TCP or HTTP).
The spec makes it very easy to have the client and server in different architectures, which is good - plus it is extensible.
Caveat: I'm the author of one of the .NET versions, so I may well be biased ;-p
First off, UDP is primarily a one-way broadcast transport method. Also, it is potentially lossy, so you need to be able handle missing packets and out-of-order packets. If you need any level of reliability from UDP, or require two-way connections, you will end up needing just about everything from TCP, so you might as well go with that to start with and let the network stack take care of it.
Next up, if your data is potentially larger than a single IP packet then you will need some way of identifying the start and end of each packet, and a means of handling illegal or corrupt packets. I would recommend some kind of header with packet length, some kind of footer, and maybe a checksum.
Then you need some way of encoding the messages and responses. There are many RPC protocols around. You could look at SOAP, or design a custom XML-based protocol, or a binary one.
You should really think hard about whether you really want to design, document and maintain your own protocol or use something that is already existing. It is probable there is already a documented protocol that matches your needs. Depending on what you are doing it will probably look overkill at first and implementing all the spec will look tedious and a lot less fun than writing your own but if you intend for your application to still be actively developed in a few years it should save you a lot of time and money to use something that already exist and is known by third parties. Besides, if you can use an existing library for that protocol, the implementation part should be a lot faster.
Designing new protocol is more fun than implementing one but less than maintaining one as you have to live with all the defects. No protocol is perfect but if you have never designed one you can be assured you will make more mistake designing it than the people who designed the existing well known protocol you could use instead.
In short, leverage what already exists whenever possible.
If you're choosing XML keep in mind that you will have a giant overhead of markup.
A simple binary protocol will also be need not so much ressources to parse compared to xml.
If you do not want to build your protocol from ground up, you should take a look at SOAP. Support varies for different programming languages, but cross language communication is explicitly encouraged.
Unfortunately UDP and SOAP seem to have stuck in its infancy, HTTP is most commonly used.
I have an existing standalone application which is going to be extended by a 3rd-party, using a network protocol.
It would help to know a little more about what your program does and what the nature of these 3rd party extensions are. Maybe some rationale for using UDP?