Recent

Author Topic: [SOLVED] TCP/IP Question  (Read 1329 times)

Petrus Vorster

  • Full Member
  • ***
  • Posts: 239
[SOLVED] TCP/IP Question
« on: March 02, 2026, 02:06:47 pm »
HI all

https://forum.lazarus.freepascal.org/index.php?topic=28575.0

I came across this example while looking for a SIMPLE TCP/IP solution on a LAN.
It works like a charm.

Now before I break stuff, this has a LISTEN with a timeout on a thread and a send which is reasonably understandable.

I have the idea of sending constructed strings like a JSON type string to a specific IP listener and that updates some record there. The same of that user have to update e.g. a open ticket status.

A server app is out of the question. EVER.

If you need to send messages to pc's over a LAN or WAN, would this work for you? Or how would you do something like this?
The LISTEN will have to be on most of the time or as long as the app is running.

I hope this is clear, I tend to explain terribly.

-Regards, Peter

« Last Edit: March 03, 2026, 07:50:19 am by Petrus Vorster »

cdbc

  • Hero Member
  • *****
  • Posts: 2667
    • http://www.cdbc.dk
Re: TCP/IP Question
« Reply #1 on: March 02, 2026, 03:06:01 pm »
Hi Peter
Build the app, so that it can act as both Client & Server, you could even 'full duplex' it
Regards Benny
If it ain't broke, don't fix it ;)
PCLinuxOS(rolling release) 64bit -> KDE6/QT6 -> FPC Release -> Lazarus Release &  FPC Main -> Lazarus Main

Petrus Vorster

  • Full Member
  • ***
  • Posts: 239
Re: TCP/IP Question
« Reply #2 on: March 02, 2026, 03:46:30 pm »
Hi Benny

That would be the plan eventually.
I tried the basics one a small LAN and that worked, Tomorrow we will try two cities. Then try it on a WAN cross-country.

The idea is a few people across the country updating a local record, then assign the work to someone else in another province. Only that person will get his message and gets updated.
We no longer have REMEDY and we are just throwing ideas around.

-Peter

LeP

  • Full Member
  • ***
  • Posts: 198
Re: TCP/IP Question
« Reply #3 on: March 02, 2026, 03:52:03 pm »
I didn't see the examples, but for sure work over a LAN is normally more simple that work over a WAN.

You cannot simply trasmitt a network packet when there ia a "filter" on the network, like all the WAN have.
Those include firewall, router, managed switch, vlan, vpn, etc ...

So, without a server (thinking as a service server) is difficoult make such things in general.

Insetad if you can have a WAN with open and NAT ports (really, no one administrator permits to have that),  the LAN and WAN is near the same and you can do what you want.

I use Indy in Delphi and it was really simple to do what you want and perhaps the examples (that were presented from evaluable member of this forum) are goods too with Synapseor others.

Remember that, in this era, all comunications should be protected and so you should (MUST ?) implement SSL comunications (... TLS technically) or other means to encrypt and secure the comunications.

« Last Edit: March 02, 2026, 03:55:17 pm by LeP »

Petrus Vorster

  • Full Member
  • ***
  • Posts: 239
Re: TCP/IP Question
« Reply #4 on: March 02, 2026, 04:27:32 pm »
Hi

Remember winpopup?
We used to run that little thing all over the place.
I was hoping to do something like that, but just formatted strings.

Here it is not about security of the message. Its merely an attempt to update a simple record on a user elsewhere on the network.
I don't expect miracles, and this is just a little trail and error attempt.

The server is managed by an external comms company, so I can forget that route.

Tomorrow we will know If this worked in a Regional Lan, by Friday NAtional. Just an experiment.
This will anyway be limited to the recipient having his pc on.

would be really cool if I could get this going.

-Peter

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 12706
  • FPC developer.
Re: TCP/IP Question
« Reply #5 on: March 02, 2026, 04:44:32 pm »
I simply have a bunch of (Indy based) UDP servers that broadcast packets for small signalling and updates, mostly between PCs and I/O boards.

The network is basically a set of measuring equipment centred around a conveyor belt (a measuring street in the lingo).

The PCs mostly communicate (measuring results) using indy TCP client/server though.


Petrus Vorster

  • Full Member
  • ***
  • Posts: 239
Re: TCP/IP Question
« Reply #6 on: March 03, 2026, 07:49:57 am »
Greetings

Surprisingly, this worked over a WAN.  :D  :D  :D
Gastly slow, but Surprisingly Worked. We could chat in text hundreds of KM away.

I am not going to really pursue  this, it was an experiment and a server base approach is out of the question, so control over what goes where will not be possible.

But thank you all, this had been a fun test.

-Peter

LeP

  • Full Member
  • ***
  • Posts: 198
Re: TCP/IP Question
« Reply #7 on: March 03, 2026, 10:09:01 am »
Surprisingly, this worked over a WAN.  :D  :D  :D

I'm not sure whether to be happy or alarmed. The fact that you were able to communicate between internal points of a WAN without any configuration would worry me quite a bit.  :o

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 12706
  • FPC developer.
Re: TCP/IP Question
« Reply #8 on: March 03, 2026, 11:59:02 am »
Greetings

Surprisingly, this worked over a WAN.  :D  :D  :D
Gastly slow, but Surprisingly Worked. We could chat in text hundreds of KM away.

Winpopup used netbeui on standalone machines that was limited by BOOTP size of the network (which could be very large though, at the uni where I worked then it worked over 14000 employees (real and "scientific" like Phd students and other postdocs). In large systems it went over the domain controllers. I don't know if it was limited by the domain or the forest (the win2000/2k3 hierarchy of domains) though.

However in 2000-2003 this was all on the way out. The various worms showed that there had to be at least some network limitations, and that legacy services posed a risk. It was also before the broad rollout of security software and OS level firewalls on every machine.

So it either was the naive time, or (if both participants were in the same domain or forest) under the hood a heavily server based application.

Either which way, those times are gone, and server less is very hard for WAN purposes, and the only solution are either to let things run over a server (like e.g. Teamviewer), or work with tunnels and VPNs. But in all cases for very broad deployment expect problems with firewalls and antivirusses.

 

TinyPortal © 2005-2018