I have looked for a native FPC TCP/IP socket to use as a replacement for a serial port component and I discovered the ssockets unit that ships with FPC and contains a TInetSocket class.
This seemed useful.
So I put together a test console application in Lazarus 1.4.0 where I had this in order to verify that FPC would find it: [code]
procedure TSSRemoteTestApp.DoRun;
var

  ErrorMsg: String;
  FSSConn: TInetSocket;

begin

  //Stuff added by Lazarus removed .....
  { add your program here }
  FSSConn := TInetSocket.Create('10.0.0.2', 2001);
  // stop program loop
  Terminate;

end;
[/code]
After I added the ssockets unit to the uses clause this compiled and so it seems like it will work.

My next problem is actually finding some description on what one can do with that object...
Is there somewhere a comprehensive guide on usage of this socket in a simple case as mine:
- Connect once and keep connection until end of program
- Send commands and binary data via a TCP/IP socket to the other end
- Fire an event when there are data received so they can be handled

I think that TInetSocket is actually blocking so I would have to use some thread or such to retrieve incoming data and decode that and feed it to the main program level for processing.
But how? I have only minimal info on what the TInetSocket can actually do.
When I google TInetSocket I get results that are not referring to this they refer to general TCP/IP articles or
descriptions of OTHER socket implementations. :(

My reason for this:
I have a quite large Delphi project for communications via RS232 to a data collection system. This was developed over several years. Now I need to create a new application that must run on an ARM embedded platform (first test will be Raspberry Pi2) and communicate via WiFi to the data collection system. It must use my existing Delphi7 classes to control the instrument and manage the data, but replace the RS232 component with a TCP/IP socket component available on FPC.
The data shifted through the socket will be EXACTLY the same as was earlier transferred by RS232.

Any suggestions on where I can find suitable documentation?

Shortly said: There is none.

If the various demo programs are not understandable for you, you are out of luck :(

Now, from what you describe, all you need to do is use the read/write methods to send and receive data, just as in any stream: the client TInetSock is a TStream descendent.

Thread programming is not so difficult, but I am not convinced that for the use case you describe, threads are really needed (despite suggestions to the contrary on this list).

Michael.

I'd suggest that the bottom line there is making the socket code oresent the same interface as the existing RS232 code.

I've not used it so I'm not happy giving advice, but Google definitely turns up a few TInetSocket examples, such as

http://ejemplos.mis-algoritmos.com/programa-cliente-de-tinetsocket

I agree that it's unfortunate that there's not one in the fcl-net package itself, but (again via Google) there's a minimal example in fcl-web/src/base/fcgigate.pp which might help. Also via a local grep I notice references in fcl-base/examples/dsockcli.pp and utils/debugsvr/dbugintf.pp which might turn out to be useful.

Thanks for the pointers!
Back in September I was looking for the solution on this but at the time not yet on an RPi2, but on Windows. I was also then adviced to search for an example of TInetSocket and had a look at ssockets usage in the example:
lazarus\fpc\2.6.4\source\packages\fcl-base\examples\dsockcli.pp

But the example is pretty limited regarding how one actually communicates using the sockets provided by ssockets. All it seems to do is to connect to a server and write the same line of text 10 times over and then quit.

What I must do is plug a socket into the existing code where there is bidirectional data transfers using a receive event and there will be a response for each packet sent.
In another thread on the fpc list I was directed towards an example I could download from:
https://github.com/silvioprog/tcpipcomp

And it looks more complete, there is a chat example which implements a bidirectional system using a thread too.
I will try to stuff this into the existing code if possible...

As Mark Morgan Lloyd has pointed out I *really* need to create an encapsulated class for the TCPIP communications so I can use this as an alternate component in the existing object and for this I need to implement an onReceive event to plug the incoming data into it. Otherwise I am in for a really big rewrite of the class.

Struggling on...

Although I think that was more in the context of trying to keep everything together if handling e.g. both serial comms and something over a socket.

I usually end up with odd requirements that force me to go to low-level serial port access, or a low-level socket... needing to log times accurately, a special-purpose telnet server and so on. The result of this is that I'm often better served with a low-level thread (and possibly select() calls etc.), with the interface to the main program being a buffer.

So find some way of encapsulating stuff, but I'd suggest not focussing on that to the exclusion of getting the main job done.

Bo Berglund wrote

As Mark Morgan Lloyd has pointed out I *really* need to create an encapsulated class for the TCPIP communications so I can use this as an alternate component in the existing object and for this I need to implement an onReceive event to plug the incoming data into it

Sorry to be a PITA, again, but a command line application (which in the other message you said you would want to do) does not support throwing events from threads out of the box. (There is no Lazarus Linux workalike for a Delphi Service Application.). You would have to implement your own "main loop" to make this happen.

That is why, to use the standard Lazarus and Delphi programming paradigms, I suggested to do a normal Lazarus GUI application on the RasPi.

-Michael

Which is fine as a testbed, but not necessarily for production use. It's particularly not fine if you want to start it on a regular basis from cron or whatever, which I think Bo has already settled on.

I'm very much in two minds on this. I'm intermittently working on a couple of fairly large programs which have elements of both daemon and UI, having them as standard Lazarus apps makes inspection and debugging much easier but inserts a large amount of complexity- X11, the widget set (GTK or Qt), all of the LCL stuff- all of which has the potential for bugs and unintended interactions.

Even if Bo did decide not to use cron but instead to have a Lazarus app with its own embedded timing, he'd still have to organise startup and having a screen- real or simulated- to run it on. And since a Raspberry Pi needs a keyboard etc. in order to have a local screen, and since he's not sorted out automatic VNC startup etc., I don't think this is the way for him to go.

So noting your concern with events, the real question is still which libraries etc. he should be running to implement a socket client reliably in a console program. Or alternatively, how best to implement a Windows-style service using Lazarus, which doesn't mandate a screen and an initial login.

Mark Morgan Lloyd wrote

Which is fine as a testbed, but not necessarily for production use. It's particularly not fine if you want to start it on a regular basis from cron or whatever, which I think Bo has already settled on.

I fully agree: doing a cron-driven timing and porting Delphi code does not go together well.

-Michael

In a private message I suggested to him to try (and supposedly help to improve) my "ActiveNoGui" Widget Type (Linux) Library that is intended as a workalike for a Delphi Service-Application.

But same needs fpc 3.x and Bo does not want to move to same.

-Michael

If that's something you're actively working on it would sound like an eminently sensible suggestion.

But same needs fpc 3.x and Bo does not want to move to same.

I think that reluctance is ungrounded, and I'd hope that as he builds up more confidence on Linux he'll reconsider.

Mark Morgan Lloyd wrote

If that's something you're actively working on it would sound like an eminently sensible suggestion.

I had been working on that on and off (and discussing it here) for a long time, but there had been no point in pushing it (once I were not in need of using it myself any more), before fpc 3.x is an official release so that a non-svn-user would be able to compile it (and hence would break Lazarus in case it would be included).

-Michael

Tracking the "best" version of FPC for any given Linux release can be tricky. In retrospect it's unfortunate that the Lazarus 1.0 release wasn't delayed until FPC 3.0, as a memorable combination against which programs meant for distribution to people who didn't normally run FPC etc. could be tested.

In practical terms, there have been a number of "must-have" features in the IDE and LCL- frames as a particular example- which have mandated moving onto a "bleeding-edge" FPC. My experience with Lazarus-1.4.0 and FPC 3.0 rc1 has been generally good, particularly once I'd moved off 2014-era Raspbian.

Lazarus' official releases are a lot more frequently than fpc's. So an addition to Lazarus that needs fpc 3.x needs to be delayed until there is an RC of a Lazarus version that officially is recommended to be used with fpc 3.x and hence will be "Bundled" with same in distributions.

-Michael