Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2015-07

Basic Sockets in FreePascal

9 messages · 5 people · –

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Coyo

I have read on the wiki and documentation that FreePascal does not have any native support for socket handling, and that you need an external third party library to have any support for it.

I want to write an IRC bot in FreePascal, but I need the ability to both make outgoing connections to IRC servers or other bots of the same kind, as well as accept incoming connections from other bots.

I'd prefer as straightforward TCP sockets support as I can get. Any advice would be greatly appreciated. Thank you in advance for your time and patience.

Reply by email

Michael Van Canneyt
to Coyo
Coyo wrote
I have read on the wiki and documentation that FreePascal does not have any native support for socket handling, and that you need an external third party library to have any support for it.

This is not correct.
Of course Free Pascal has native support for socket handling ?

I want to write an IRC bot in FreePascal, but I need the ability to both make outgoing connections to IRC servers or other bots of the same kind, as well as accept incoming connections from other bots. I'd prefer as straightforward TCP sockets support as I can get. Any advice would be greatly appreciated. Thank you in advance for your time and patience.

Just use the sockets or ssockets units.
The first is plain pascal and a straightforward interface as you encounter it in any C implementation, the second is using classes.

Michael.

Reply by email

Ewald
to Coyo: I have read on the wiki and documentation that FreePascal does not have any native…
Coyo wrote
I have read on the wiki and documentation that FreePascal does not have any native support for socket handling, and that you need an external third party library to have any support for it.

How about `uses sockets;` [1]? Basically it's the same as you would have in C, but all functions are prefixed `fp` (as are most other low level functions on *nix BTW).

[1] http://www.freepascal.org/docs-html/rtl/sockets/index-5.html

Ewald

Reply by email

Mark Morgan Lloyd
to Michael Van Canneyt: This is not correct. Of course Free Pascal has native support for socket handling ? Just…
Michael Van Canneyt wrote 8 lines
On Sun, 26 Jul 2015, Coyo wrote: > I have read on the wiki and documentation that FreePascal does not > have any native support for socket handling, and that you need an > external third party library to have any support for it. This is not correct. Of course Free Pascal has native support for socket handling ?

Knowing the URL of that wiki page would be useful, so that we can fix it if it really is broken. What version of FPC is the documentation for?

Show quoted text 11 lines
> I want to write an IRC bot in FreePascal, but I need the ability to > both make outgoing connections to IRC servers or other bots of the > same kind, as well as accept incoming connections from other bots. > > I'd prefer as straightforward TCP sockets support as I can get. Any > advice would be greatly appreciated. Thank you in advance for your > time and patience. Just use the sockets or ssockets units. The first is plain pascal and a straightforward interface as you encounter it in any C implementation, the second is using classes.

Seconded, it's something I do on a regular basis when I have to do something with a non-standard protocol. However I think there's a couple of points worth considering.

The first is that the Pascal /language/ doesn't have implicit support for sockets, you need to import an appropriate unit/library. That's going to be the case for almost all general-purpose languages, with the exception of things like Perl and Python which try to build in everything a programmer might need including the kitchen sink.

The second is that for standard protocols like FTP and HTTP it might be better to use a third-party library to avoid reinventing the wheel when it comes to security etc., some of these- for example Synapse- are routinely used by almost everybody but aren't packaged with FPC because their developers prefer to stay independent.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email

Coyo
to Mark Morgan Lloyd
Show quoted text 9 lines
Michael Van Canneyt wrote: > On Sun, 26 Jul 2015, Coyo wrote: > >> I have read on the wiki and documentation that FreePascal does not >> have any native support for socket handling, and that you need an >> external third party library to have any support for it. > > This is not correct. Of course Free Pascal has native support for socket > handling ?

I will link the wiki articles later to demonstrate the difficulty of using sockets in FPC. However, I do appreciate the advice.

How do you import a unit/library in FPC? Is there a .deb package or something that I install?

When compiling or distributing compiled FPC codebases that use external units or libraries in FPC, how do you go about doing that? I failed to find documentation illuminating how one goes about doing this. Any enlightenment would be greatly appreciated.

Show quoted text 14 lines
Knowing the URL of that wiki page would be useful, so that we can fix it if it really is broken. What version of FPC is the documentation for? >> I want to write an IRC bot in FreePascal, but I need the ability to >> both make outgoing connections to IRC servers or other bots of the >> same kind, as well as accept incoming connections from other bots. >> >> I'd prefer as straightforward TCP sockets support as I can get. Any >> advice would be greatly appreciated. Thank you in advance for your >> time and patience. > > Just use the sockets or ssockets units. The first is plain pascal and a > straightforward interface as you encounter it in any C implementation, > the second is using classes.

I dislike object oriented programming, it makes something that should be very simple, compact and portable to something more complex than it really has to be. But that's just a personal preference. Thankfully, FPC lets me use purely functional programming if I prefer to do so. Java and new Perl force object oriented programming down my throat, and is part of the reason I have a deep interest in FPC. I want to keep it stupid simple.

I prefer, when possible, to avoid using external dependencies, and to keep all code in a single file. While I am not a supergenius coder or anything, I CAN appreciate elegantly-written code. Compact source code and compact binaries are something I can appreciate. Overuse or gratuitous use of external libraries and dependencies disturbs me.

I do not know how to use external libraries in C, as it seems more complex than it's really worth. All functions I ever use are in a single C file. Reinventing the wheel? I don't want to seem ungrateful, and my mother taught me that if you can't say something nice, don't say anything at all.

Well, that's something a mother would say if I actually had one. I think. Anyway, I will not remark on what I think of this aversion to multiple implementations of things others have written questionably usable code to do. I don't want to be mean about this, after all, any advice you give here is free. Don't look a gift horse in the mouth, right?

I don't mean to be irritable, but I've heard "don't reinvent the wheel" far too many times, especially when defending centralized or dangerously homogenous networks and systems, rather than multiple implementations and diversity in network components and systems.

One can argue over-reliance on a single implementation of a cryptographic library, namely OpenSSL, is actually a security RISK rather than a benefit. See: Heartbleed. ONLY OpenSSL-dependent applications, systems, and services were affected by that programming failure.

Anyway, that's another topic entirely, and not something I want to get into on this list, as it is off-topic, and I want definitive answers on how to do sockets in pure FPC, rather than using netcat or some external program via shell scripting.

The IRC bot I have now uses a shell script to invoke it, and establishes the connection using netcat and standard input/output. I want to eliminate netcat from being a dependency. I can worry about TLS and whatnot later.

Show quoted text 9 lines
Seconded, it's something I do on a regular basis when I have to do something with a non-standard protocol. However I think there's a couple of points worth considering. The first is that the Pascal /language/ doesn't have implicit support for sockets, you need to import an appropriate unit/library. That's going to be the case for almost all general-purpose languages, with the exception of things like Perl and Python which try to build in everything a programmer might need including the kitchen sink.

I'm used to Perl, Python and Ruby, which all have systems of making using standard libraries trivial. C doesn't really have anything like that.

Show quoted text 5 lines
The second is that for standard protocols like FTP and HTTP it might be better to use a third-party library to avoid reinventing the wheel when it comes to security etc., some of these- for example Synapse- are routinely used by almost everybody but aren't packaged with FPC because their developers prefer to stay independent.

I would greatly appreciate a definitive answer on how to go about using Synapse for things, since the wiki and docs I have found are either ancient, inconsistent, unclear, or incomplete. I would be happy to update the wiki, if you want me to.

The reason I want to have sockets internal to FPC instead of using an external tool such as netcat is because I want to use one of the core features of FPC, namely portability of code. FPC has incredible code portability. It is trivial to compile code for a huge selection of target platforms, and I would prefer my code to be as portable as possible, and rely on as few dependencies as possible. However, implementing an entire userspace TCP/IP protocol stack in FPC is something I am NOT ready to do at this time, especially for a simple IRC automaton. Maybe later...

Show quoted text 8 lines
-- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] _______________________________________________ fpc-pascal maillist - http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-pascal
Coyo

Reply by email

Coyo
to Ewald: How about `uses sockets;` [1]? Basically it's the same as you would have in C, but all…
Show quoted text 11 lines
On 07/26/2015 04:49 PM, Coyo wrote: > I have read on the wiki and documentation that FreePascal does not have any native support for socket handling, and that you need an external third party library to have any support for it. How about `uses sockets;` [1]? Basically it's the same as you would have in C, but all functions are prefixed `fp` (as are most other low level functions on *nix BTW). [1] http://www.freepascal.org/docs-html/rtl/sockets/index-5.html -- Ewald

Thank you very much! I'll be sure to read all of that!

Coyo

Reply by email

waldo kitty
to Coyo: On Sun, 26 Jul 2015 15:47:52 +0000 I will link the wiki articles later to demonstrate the…
Coyo wrote
How do you import a unit/library in FPC? Is there a .deb package or something that I install?

hunh?? is there something wrong with the standard ""uses foo, bar;"" clause??

NOTE: No off-list assistance is given without prior approval. *Please keep mailing list traffic on the list* unless private contact is specifically requested and granted.

Reply by email

Michael Van Canneyt
to Coyo: On Sun, 26 Jul 2015 15:47:52 +0000 I will link the wiki articles later to demonstrate the…
Coyo wrote 18 lines
On Sun, 26 Jul 2015 15:47:52 +0000 Mark Morgan Lloyd wrote: > Michael Van Canneyt wrote: >> On Sun, 26 Jul 2015, Coyo wrote: >> >>> I have read on the wiki and documentation that FreePascal does not >>> have any native support for socket handling, and that you need an >>> external third party library to have any support for it. >> >> This is not correct. Of course Free Pascal has native support for socket >> handling ? I will link the wiki articles later to demonstrate the difficulty of using sockets in FPC. However, I do appreciate the advice. How do you import a unit/library in FPC? Is there a .deb package or something that I install?

You don't need to import anything. The sockets unit is distributed with Free Pascal by default. It talks straight to the system kernel. Just put 'uses sockets' in your uses clause.

Show quoted text 5 lines
When compiling or distributing compiled FPC codebases that use external units or libraries in FPC, how do you go about doing that? I failed to find documentation illuminating how one goes about doing this. Any enlightenment would be greatly appreciated.

I don't understand this question ?

Michael.

Reply by email

Mark Morgan Lloyd
to Coyo: On Sun, 26 Jul 2015 15:47:52 +0000 I will link the wiki articles later to demonstrate the…
Coyo wrote 17 lines
On Sun, 26 Jul 2015 15:47:52 +0000 Mark Morgan Lloyd wrote: > Michael Van Canneyt wrote: >> On Sun, 26 Jul 2015, Coyo wrote: >> >>> I have read on the wiki and documentation that FreePascal does not >>> have any native support for socket handling, and that you need an >>> external third party library to have any support for it. >> This is not correct. Of course Free Pascal has native support for socket >> handling ? I will link the wiki articles later to demonstrate the difficulty of using sockets in FPC. However, I do appreciate the advice. How do you import a unit/library in FPC? Is there a .deb package or something that I install?

Most of what you need comes as part of FPC. There's a very rough split between the Run-time Library (RTL) and Free Class Library (FCL), all you need is the uses statement.

When compiling or distributing compiled FPC codebases that use external units or libraries in FPC, how do you go about doing that? I failed to find documentation illuminating how one goes about doing this. Any enlightenment would be greatly appreciated.

Most of what you need comes as part of FPC.

Show quoted text 12 lines
I dislike object oriented programming, it makes something that should be very simple, compact and portable to something more complex than it really has to be. But that's just a personal preference. Thankfully, FPC lets me use purely functional programming if I prefer to do so. Java and new Perl force object oriented programming down my throat, and is part of the reason I have a deep interest in FPC. I want to keep it stupid simple. I prefer, when possible, to avoid using external dependencies, and to keep all code in a single file. While I am not a supergenius coder or anything, I CAN appreciate elegantly-written code. Compact source code and compact binaries are something I can appreciate. Overuse or gratuitous use of external libraries and dependencies disturbs me.

I'm afraid that you're going to have to get used to pulling in units from the RTL and FCL, and some of these mandate using OO. If it gives you problems then ask for help.

I don't mean to be irritable, but I've heard "don't reinvent the wheel" far too many times, especially when defending centralized or dangerously homogenous networks and systems, rather than multiple implementations and diversity in network components and systems.

I would very strongly recommend against trying to reimplement a complex protocol from scratch. You'll make the same mistakes that early implementers made, and your code will be vulnerable to the same attacks.

One can argue over-reliance on a single implementation of a cryptographic library, namely OpenSSL, is actually a security RISK rather than a benefit. See: Heartbleed. ONLY OpenSSL-dependent applications, systems, and services were affected by that programming failure.

Ditto.

The IRC bot I have now uses a shell script to invoke it, and establishes the connection using netcat and standard input/output. I want to eliminate netcat from being a dependency. I can worry about TLS and whatnot later.

If you're invoking netcat as an external program to handle your comms you're doing something very badly wrong. Netcat (and equivalents such as netpipes, i.e. hose/faucet) is great at what it does which is handling scripted socket access, but you really shouldn't be using it as part of custom code.

I'm used to Perl, Python and Ruby, which all have systems of making using standard libraries trivial. C doesn't really have anything like that.

I don't much like seeing that, but I suppose the assertion is justifiable since you usually need to specify both a .h file and the name of a library. For FPC, you only need a uses statement, the linker side is done automatically.

I would greatly appreciate a definitive answer on how to go about using Synapse for things, since the wiki and docs I have found are either ancient, inconsistent, unclear, or incomplete. I would be happy to update the wiki, if you want me to.

If there's something that's giving you trouble in the Wiki please give us a URL and tell us what the ambiguity or error is.

Show quoted text 8 lines
The reason I want to have sockets internal to FPC instead of using an external tool such as netcat is because I want to use one of the core features of FPC, namely portability of code. FPC has incredible code portability. It is trivial to compile code for a huge selection of target platforms, and I would prefer my code to be as portable as possible, and rely on as few dependencies as possible. However, implementing an entire userspace TCP/IP protocol stack in FPC is something I am NOT ready to do at this time, especially for a simple IRC automaton. Maybe later...

Do not even dream about trying to implement an IP stack from scratch. I've done that sort of thing for very specific purposes (e.g. a test program that's trying to work out whether it's still our kit at the other end of a modem link, or if somebody has replaced it with something running PPP), and I'd probably have done far better by linking in code from Slirp or equivalent.

Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues]

Reply by email