TCP/IP Sockets components in Lazarus 1.6 for Win32

[pascalbythree]

Are these really not defaultly included?, Anybody a name/URL for a TCP/IP component pack for Lazarus/Win32
Greets, Wouter van Wegen

[Leledumbo]

Nope. But you have plenty of options:

• lNet
• (Visual) Synapse
• Indy

Components are sometimes overrated for tasks like this, but it depends on your design anyway. I would choose libraries over components, though. Not to mention that socket related units are shipped by default.

[JD]

Add the Fundamentals 5 library (no components, though) to that:

https://github.com/fundamentalslib/fundamentals5

JD

[marcov]

And some versions of ICS also work

[fireday2]

When developers will add to the standard build Lazarus components tcp/ip ?
what was the reason not to add controls in current version of Lazarus?

[Thaddy]

When developers will add to the standard build Lazarus components tcp/ip ?
what was the reason not to add controls in current version of Lazarus?

How do you visualize a TCP/IP connection? Bit of a nonsense.
FPC contains many ways to use TCP/IP (but you really mean sockets which is something different) in its standard distribution.
If you want components (which is nonsense IMNSHO) use Indy. Easy to use and well maintained.
If you want performance, use something else, though.
And indeed as Marco says ICS also works well (better than Indy).

I do not know the state of visual synapse because I never used it, but Synapse itself is extremely good and performant. It is my default goto.
But fcl-web is getting better and better all the time, is in the standard distribution, cross-platform and performant as well.
These are classes, not components.

[Leledumbo]

When developers will add to the standard build Lazarus components tcp/ip ?

I don't think there's something like that in the plan.

what was the reason not to add controls in current version of Lazarus?

No contributor/maintainer? Everything in Lazarus is a volunteer act, not as plan driven as in other similar projects. If a contributor is willing to do the work, it will be there. If not, it won't. Even releases don't have actual milestones, they're set when changes in trunk from latest release are considered big enough and only then branches to stop feature addition patches.

[fireday2]

sry for my eng 
I meant a set of components for TCP/UDP
as an example, the sockets in MVS

[molly]

sry for my eng 
I meant a set of components for TCP/UDP
as an example, the sockets in MVS

here are some links at the bottom.

As already mentioned in this thread, having (non-)visual components for socket programming is really nonsense.

[Thaddy]

So what you want is just sockets.
Well, this works out of the box

Code: Pascal  [Select][+][-]

1. program testsockets;
2. uses sockets;
3. begin
4. end.

Ok, bit short, but is cross-platform and contains all the functionality you need...

[marcov]

Ok, bit short, but is cross-platform and contains all the functionality you need...

So how do you wait on a socket and do something else using the sockets unit and other crossplatform units ?

[vfclists]

Components can wreak havoc on your revision control, although in the case of non visual components it may not be so bad.

Try merging differences between a project compiled on Linux and the same one compiled in Windows and you will see what I mean.

Even with UI objects things would be much better if there were some tools to convert .lfm files into pascal source code, unless streaming them in and out at runtime is important to you.

[Thaddy]

What do you mean, Marco?
Programmers responsibility and capability?

The sockets unit is cross-platform and sufficient for TCP/IP.

[marcov]

What do you mean, Marco?
Programmers responsibility and capability?

I mean sockets is a header, not an abstraction.  You can only do blocking I/O with it, since select and waitfor* are OS dependent and not abstracted, not very conductive for a gui.

So IMHO it is not right to suggest the socket unit as an even minimalistic equivalent for the socket suites. A crucial part is missing. 

Personally, while I knew ICS better at the time (this is Delphi6 anno 2000-2003), I switched to Indy(9) because it was the first with fairly out of the box secure sockets support (to be downloaded on some site with a  Yugoslavian domain, but still).  I then upgraded to Indy10 on both Delphi and FPC.

I never used Synapse much, but I did like ICS a lot when the v6 series  was ported to FPC, specially because of the very rich examples.

[Thaddy]

What do you mean, Marco?
Programmers responsibility and capability?

I mean sockets is a header, not an abstraction.  You can only do blocking I/O with it, since select and waitfor* are OS dependent and not abstracted, not very conductive for a gui.

So IMHO it is not right to suggest the socket unit as an even minimalistic equivalent for the socket suites. A crucial part is missing. 

Personally, while I knew ICS better at the time (this is Delphi6 anno 2000-2003), I switched to Indy(9) because it was the first with fairly out of the box secure sockets support (to be downloaded on some site with a  Yugoslavian domain, but still).  I then upgraded to Indy10 on both Delphi and FPC.

I never used Synapse much, but I did like ICS a lot when the v6 series  was ported to FPC, specially because of the very rich examples.

Ah, that explains it a bit more indeed.
My point is that the sockets unit in itself covers the protocol, it is not just an interface, it is just not an implementation in itself. In that sense it is more than just a header.
In capable hands it can cover any subject regarding to TCP/IP or even more abstract: sockets.

As an aside: Synapse is also blocking oriented, but has grown to have really performant non-blocking code. I consider it so stable it doesn't need much maintenance. Which is also the case.
I just look (biased, because of background) at performance and applicability. And, note, everything else is based on that interface description in Pascal parlance.