I am trying to implement a transport layer protocol for my project. I am going to use Linux as my operating system. Could you please suggest me some books or links that explain the implementation of transport layer (like TCP)? Thank you..
Thanks,
Bala
As far as I can tell, the latest (December 2008) book dedicated to this one and only topic is
TCP/IP Architecture, Design and Implementation in Linux.
772 pages, enough to keep anyone busy for a little while.
Note that it doesn't cover UDP, deferred to a future book.
Caveat: Even though the book was released end dec 2008, the base kernel tree it describes is a 2.4.20 one. OTOH, I don't think the TCP/IP stack has changed that much since then. The author announces in his preface that 2.6 specifics will be covered in a future edition.
The book on the topic - TCP/IP Illustrated, Volume 2: The Implementation, by W. Richard Stevens the great.
Related
I'm wondering if there is a good resource for FORTH implementations on recent SOCs.
I'm mostly interested in bare metal versions, something that can sit net to RTOS on an ESP32 or RISC-V for instance (so gforth might not be ideal).
And particularly, I'm looking at least at a version that can do networking (e.g. via WIFI, ideally via a source network stack implementation, which in RTOS might not be too hard)
Sadly, it seems pretty hard to tickle useful info out of Google – it mostly seems to think I can't spell fourth. Many results I do find seem outdated, and or seem very commercial; and it feels wrong to pay licensing fees for a network stack in the age of micropython.
This Raspberry Pi JonesFORTH O/S looks pretty promising.
I wouldn't mind doing a bit of porting.
Even if your question could be interpreted as opinion-based and might be looking for resources only, I am going to provide two links to living and active maintained projects which might fit your requirements.
I'm wondering if there is a good resource for FORTH implementations on recent SOCs. I'm mostly interested in bare metal versions
You may have a look into
AmForth
... for the Atmel AVR8 Atmega micro controller family and some variants of the TI MSP430. The RISC-V CPU (32bit) is currently beeing worked on.
and
Mecrisp, Stellaris
an implementation of a standalone native code Forth for MSP430 microcontrollers
or Quintus
a rewrite of classic Mecrisp-Stellaris with almost the same look-and-feel for RISC-V architecture, RV32I, RV32IM or RV32IMC flavour, and it includes support for MIPS M4K cores. FPGAs are conquered by using FemtoRV32 softcores.
With both projects it is possible to achieve progress quite fast and easy depending what you try to achieve.
... can do networking (e.g. via WIFI, ideally via a source network stack implementation ... I wouldn't mind doing a bit of porting.
For a more detailed answer and more guidance this part would need more information and some clearance.
please could you explain to me an architecture of the LING platform? I don't understand how ling interacts with xen and then with hw - is ling vm talking to xen microkernel directly though c api?
thanks :)
I do not have an in-depth knowledge of the project but I think I can give you some pointers for further research.
1) concept of unikernel: http://queue.acm.org/detail.cfm?id=2566628
2) a podcast about this project: http://mostlyerlang.files.wordpress.com/2013/10/020-erlang-on-xen.mp3
From what I understand, based on the unikernel concept, LING has rewritten part of erlang/otp to improve the startup time and remove OS attack vectors. It also translates BEAM files to a custom instrument set.
LING communicates with Xen using 'hypercalls'. The hypercalls mostly used during inital configuration, such as setting page tables. Later the communication with virtual devices happens mostly through shared pages and (soft) interrupts. This is exactly the interface paravirtualised Linux kernel is using when running as Xen guest.
We plan to setup client and server for peachtree accounting system.
currently, we have software Sage Peachtree Quantum 2010 Accountant, so could we use this
software for making client and server?
Do you have any ideas regarding this issue?
If the Quantum still uses the pervasive database, it uses the server side database to lock the files, and is very active. Depending upon your latency of connection it may or may not work out. We used Peachtree Compete 2004 and were successful in connecting by VPN, with a mapped drive to the datapath, nut it was very slow, albeit the connections were very slow back then. So this is a no answer answer, just an encouragement to setup a VPN and give it a try. Our last current version is Peachtree apremium, and it will not run this way, nor will it run under terminal services, which is an alternate solution. However, I am told that the latest versions will run under terminal services, as we are considering upgrading to such. Sage's tech support is junk, so do not look directly to them for much help, however there are a lot of good VAR support companies that vary in competence and may be good for some assistance. Good luck.
For example, are they using Java/Struts? Or ASP.NET? Or PHP? Or some combination of technologies?
Not sure how public they are about their infrastructure, but it would be very interesting to know what they use.
Not sure if this is what you are looking for, but see here: http://en.wikipedia.org/wiki/Second_Life#Technology
As is often the case with such questions, High Scalability has an overview of the Second Life architecture, plus links to presentations by SL staff and other resources.
I will take a wild guess, a combination of scripts running on a server written in C++.
While this is an antique question, I'm surprised that no one mentioned OpenSimulator or some other Sim application. OpenSimulator will allow you to run your own Second Life clone on your own hardware and with one of the many SL viewers that are out there, you could just connect to your own virtual world. And this World would be very similar to SecondLife, including it's scripting language!
OpenSimulator is written in C# back in 2007 using the Second Life Protocol to be very identical, although they don't strive for complete compatibility.
The Firestorm Viewer is also open source as Linden Labs once published the source code of their viewer using an LGPL license. But the Firestorm team doesn't make access to the source code easy to find. (It is here!) You will need to know C++ to understand the code.
So, Second Life is made from three parts: Server, client and a special protocol that goes in-between. As Second Life is old, it also uses some older techniques and protocols as developers generally don't fix things that aren't broken. Then again, this question is also old and I'm not even sure if anyone is still interested in Second Life.
Still, if someone is still interested then this gives some nice additional information.
I never liked components for winsock programming,I loved it in its natural way,but today my collegue told me to use Indy for my project.Could you tell me if Indy better alternative for my project?
-2 TCP servers,2 TCP clients.4 sockets total
-The project is a proxy.
And now the second question,I read daily that WSAASyncSelect is not good and that's predictable,it's from winsock 1.1.My question is: Suggest something better than AsyncSelect for winsock-by-hand.
Thank you.
My preference tends to lean on synapse for all of my socket work because of its light and easy to understand approach. It is not a component architecture, but a class architecture and implementation is generally as simple as copying one of the existing helper classes and modifying it to perform the exact steps needed. Synapse also has a great user community, and is being actively developed so get the latest changes from the svn snapshot (I believe its revision 98, the website has a zip of revision 38).
Yes, Indy is much better because it provides you with consistent abstraction of winsock communication. The difference is like creation windows using WinApi and simply using TForm.
Yes, Indy is better. So is ICS, or Synapse, or any of the other internet-related component sets. They handle all of the minutia and let you work on your application's actual functionality instead of wasting your time on the communications layer details. They're also much more well tested (because of the broader user base and wider range of hardware and operating systems) than your own code could ever hope to be.
NIH (Not Invented Here) is a really bad idea if there are well-constructed, well-maintained, and widely used alternatives available, especially when those alternatives are free with source (like Indy and ICS).