[lazarus] Working with Sockets

[matooo at email.si]

Quoting Michael Van Canneyt <michael.vancanneyt at wisa.be>:

> 
> 
> 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 ?
> 

So, I did. 
But last time I was making a suggestion, there was all talk and talk and talk.
But nobody did something. Ok, I did what I needed but you obviously weren't
prepared to take it as I suggested, so I completed my suggestion for my use and
you probably did yours I really don't know because until week ago I was still
working with the same version as almost a year ago. Now that I'm finished with
my project I can finally move on (I really hated new delphi version, so I never
trust nobody to swap the tool I'm using between a project in work). But what I
saw was two things, except Interfaces, everything worked out fine, great work
every time delphi got upgraded I almost suffered mental attack.
And some bugs that stayed the same as I noted "in my special conditions".

> 
> >
> > 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.
> 

Read the book "The Linux Kernel". It explains all. No threading one connection
or you're going the wrong way against the principles of suggested kernel
programming.

> 
> >
> > 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)
> 

So I will, but my solution is heavy on threading already in motion. If that's no
problem? My guess after reading your response is that you don't like that.

> >
> > 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.
> 

So, I should???? heh, ???in XMLReader.ExpectProlog that function throws out if
there is something after the end, and notify nobody that it is unsuccessful.
Component is not assigned and result is not nil, a bug I guess.

There is no exceptions in XMLRead, at least I haven't seen them. And if I
produce exception I finally get a load of unspecied allocated memory.

Problem is "not all xml files get written by your component, beacuse if file is
written with it it's complying with xml specifications", make one from a script
or some other language that produces xml file with a bug.

So, is it a bug or not??? You decide. 

> >
> > 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.
> 

  FConnected := Sockets.Connect(ASocket, addr, sizeof(addr));
//  If not Sockets.Connect(ASocket, addr, sizeof(addr)) then
//    raise ESocketError.Create(seConnectFailed, [Format('%s:%d',[FHost, FPort])]);

and tell me why there should be exception on trying to connect. Nicer way,
connect runs in thread and tryes to login. Cancel thread cancel connection, or
too many tryouts cancels connection. Bug occurs in a simple console application,
in gui application your exception throws out dialog with a message, in console,
guess what whole software gets thrown out, exception or not, at least for me.

> 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'.
> 

There's no mixing, but simple explanation. The work I do is system only, almost
no gui. You obviously haven't really tested more clearly before you commented. I
noted that I'm changing GID and UID runtime and I'm always using heavy threading
and most of all I'm combining different languages, and that's where the problems
are in "multiuser", so yes they are bugs in certain conditions that do not meet
classical Lazarus app as I noted in my previous answer. 


> Michael.
> 
> _________________________________________________________________
>      To unsubscribe: mail lazarus-request at miraclec.com with
>                 "unsubscribe" as the Subject
>    archives at http://www.lazarus.freepascal.org/mailarchives
> 


-------------------
http://www.email.si