Forum > Networking and Web Programming
INET TLUDPcomponent for inter-process communications?
Curt Carpenter:
I've been using the INet TLUDPcomponent for quite a while to communicate between multiple processors and would like to use the same component now to implement inter-process communications. I've had no success though in trying to use it with LocalHost (IP 127.0.0.1 on my Linux box). Has anyone had any success in doing this? (I've been using SimpleIPC for inter-process and and TLUDP for inter-processor, but would like to just use TLUDP for everything if it can be done).
MarkMLl:
No, and I've junked it in favour of my own code on top of the standard sockets unit: it was too unreliable and difficult to debug.
MarkMLl
Warfley:
Personally I don't have that much experience with INet, but if you want to do UDP, the berkley sockets API is already not that difficult and easily usable through the sockets unit.
And if you are using trunk, you can try the new fpsockets unit which maps the berkley sockets API onto more high level pascal concepts. For how to use UDP you can just take a quick look into the test cases
If you are using linux, you may want to look at Unix Domain sockets instead, they are handled through the filesystem (virtually, nothing is written to the disk) and allow you to easily create TCP streams between different processes on the same system
MarkMLl:
The reason I used LNet initially was that I needed Telnet for a terminal emulator (to connect to the Hercules IBM mainframe emulator so I could investigate VM/CMS), and Telnet isn't sexy enough for most library developers to take seriously :-) Hence there's a slightly-modified version of LNet bundled with FPC itself.
The problem is that it's /ancient/... and that's somebody who dabbles with mainframe emulators talking. Instead of using one or more background threads- supported by just about everything later than Delphi v1- it hooks into the main event loop, and when I dove in trying to work out why a terminated server didn't release its "well known" port... well, it wasn't exactly easy and that's why I wrote my own Telnet implementation.
The people at Berkeley were pretty smart, after all that's where Wirth got his PhD so we have to give them some credit :-)
As a result the Berkeley Sockets API does its designated job pretty well: frankly, once one gets to reliable documentation and examples it's far easier to use than most of the "convenience layers" that people have tried to put on top of it: and that's particularly true for a packet-oriented protocol like UDP.
You don't need a background thread for UDP, since it's strictly packet-in/packet-out. The real weakness however it that packets can get lost or reordered: but the likelihood of that happening on an intranet let alone in the context of a single machine is negligible.
MarkMLl
Curt Carpenter:
--- Quote from: Warfley on November 16, 2024, 08:42:35 pm ---If you are using linux, you may want to look at Unix Domain sockets instead, they are handled through the filesystem (virtually, nothing is written to the disk) and allow you to easily create TCP streams between different processes on the same system
--- End quote ---
I built a pair of test programs using TUnixSocket in fcl-net ssockets, and as I recall they worked OK (unlike TInetSocket which would work OK if compiled as a program but not if compiled as a GUI app (which would crash if I tried to use the OnIdle function). I don't recall why I decided TUnixSocket wasn't what I wanted. Tried so many different approaches in the last week that I'm going blind :)
Navigation
[0] Message Index
[#] Next page