[lazarus] Working with Sockets

Michael Van Canneyt michael.vancanneyt at wisa.be
Sun Dec 8 14:06:16 EST 2002

On Sun, 8 Dec 2002 matooo at email.si wrote:

> Quoting Anders Jensen <outdoors at tiscali.no>:
> > Har anyone any knowledge about working with sockets in Lazarus?
> > I`m tearing my hair off here (and has little of it as it is) ,  trying
> > to make
> > a simple little p2p chat-client on SuSE 8.0, nuthin seems to work using
> > the sockets-unit in FPC... or maybe I`m just doin it all wrong (very
> > possible)
> >
> > AJ
> >
> Problem is larger in some ways than it seems. First major problem is that
> sockets  in ssockets unit don't respect kernel specifications for this kind of
> communications.

Well, why don't you communicate what the problems are, maybe we can solve them ?

> Basically,
> 1. In linux accept (there is no check mode, accept just waits until it gets
> result) should be run in a thread.
> 2. When accept is invoked another thread should be invoked which creates a
> socket and this socket communicates with a client.
> To conclude, No multithreading, no fun

This is not needed when running asynchronous IO. There are examples of a webserver
written in FPC using asynchronous IO. Threadprogramming makes some things easier,
but is not required at all.

> I'm making a CS socket communication and I've succesfully made all the
> components I need, which I would be glade to contribute (as well as few bugs,
> more likely security bugs and their solutions). There's just a fact that sockets
> are not 100% tested and I'm still making a TInetJob queue which takes care if
> there are more then one job for the same communication eg. copying multiple
> files in different directions. They will be completed in friday (that's my
> deadline for the project (mostly lazarus and bash cooperation) I've been working
> last 7 months and communication is the last part of it). Just tell me where to
> drop them or whom to send if you're interested. But I've corrected only
> TInetSocket not TUnixSocket, which can just follow my example with Inet.

You can send patches to me or to sebastian guenther (sebastian.guenther at freepascal.org)

> And explanation for security bugs.
> There are some problems in your components, mainly involving forceably exiting
> software after a bug. I understand that's common in Windows environment but Unix
> isn't like that. Sockets have that one too. But there is a nicer example.
> bug (XML#1)
> 1. Take xml file
> 2. Add some garbage at the end
> 3. Try to read it
> 4. Program exits with error

You should put a try/except block around it of course. this is common programming
technique in Object Pascal.

> bug (sockets#1)
> 1. Client tryes to make communication that doesn't exist
> 2. Program invokes error
> 3. Read 5 in XML bug

See same solution.

You cannot mix normal 'procedural' programming techniques
and class programming using exceptions. The 'bugs' you report
are not bugs, they are normal program behaviour, only you're
supposed to follow the programming rules under which the
components were constructed. If you don't (and you obviously don't)
then you will of course interpret this as 'bugs'.


More information about the Lazarus mailing list