🚀 go-pugleaf

"Tabir" <BCB@BCB> wrote in message news:408940c8$1@newsgroups.borland.com...
> Is there any Linux AND Windows compatible source code samples showing how
to
> build Client/Server apps using UDP and TCP/IP without any components?
>

Indy is available for Kylix, well, Indy 9, anyway.  You don't need a form -
you can just instantiate the components in code, no problemo.

That being said, the Synapse units as mentioned by Ben are exellent, (on
Windows, anyway), an have no pretensions of being components that can be
plonked on forms.

IMHO, 'blocking components' are a bit of a kludge anyway since you nearly
always end up having to instantiate them in a thread class unless you are
willing to put up with the 'application.processMessages' bodges like
TidAntifreeze.

Rgds,
Martin

"Martin James" <mjames_falcon@dial.pipex.com> wrote in
news:4089b966@newsgroups.borland.com: 
> IMHO, 'blocking components' are a bit of a kludge anyway since you
> nearly always end up having to instantiate them in a thread class unless

Lets not start this debate again - but blocking sockets are NOT a kludge. If 
I had to choose one that was a kludge - it would be not blocking ones, 
espcecially if you look at history of sockets and why message based ones were 
created under Windows.

That being said - we are talking Linux. Linux natively supports blocking 
sockets and its how nearly all servers are implemented. Thats hardly a 
kludge.

Linux does not support non blocking as Windows does. Instead in addition to 
blocking sockets it has something more similar to overlapped I/O.

Finally threads/forking is not kludge either. In fact Linux is full of them - 
and just because something is often used with it does not make it a "kludge". 

By your definition, Linux is one big kludge itself.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

   Need extra help with an Indy problem?

   http://www.atozed.com/indy/experts/

Chad Z. Hower aka Kudzu wrote:

> That being said - we are talking Linux. Linux natively supports blocking 
> sockets and its how nearly all servers are implemented. Thats hardly a 
> kludge.
> Linux does not support non blocking as Windows does. Instead in addition to 
> blocking sockets it has something more similar to overlapped I/O.

Chad, are you talking about synchronous/asynchronous or 
blocking/non-blocking? Linux does support non-blocking sockets using 
ioctl(O_NONBLOCK)

> Finally threads/forking is not kludge either. In fact Linux is full of them - 
> and just because something is often used with it does not make it a "kludge". 

In linux, where threads == processes (with some minor difference of 
threads having common memory), creation of threads takes additional time 
(not talking about the fact that it's impossible to debug secondary 
threads with Kylix or Kdbg or KDevelop's debugger).

-- 
Eugene Mayevski
EldoS Corp., CTO
Security and networking solutions
http://www.eldos.com

"Eugene Mayevski [SecureBlackbox]" <mayevski@eldos.org> wrote in
news:408cb3a2@newsgroups.borland.com: 
> Chad, are you talking about synchronous/asynchronous or 
> blocking/non-blocking? Linux does support non-blocking sockets using 
> ioctl(O_NONBLOCK)

Yes, I mentioned then. They are "non blocking" but not the same as on 
Windows. They are more like overlapped I/O.

> In linux, where threads == processes (with some minor difference of 
> threads having common memory), creation of threads takes additional time
> (not talking about the fact that it's impossible to debug secondary 
> threads with Kylix or Kdbg or KDevelop's debugger).

Yes, thats why I said threads/fork where forking on Unix is much more common, 
alhtough threading is becoming quite common as well.



--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

   Want more Indy stuff? Try the Atozed Indy Portal at 
        http://www.atozedsoftware.com/
    * More Free Demos
    * Free Articles
    * Extra Support

"Chad Z. Hower aka Kudzu" <cpub@hower.org> wrote in message
news:Xns94D754C7FDA13cpub@127.0.0.1...
> "Martin James" <mjames_falcon@dial.pipex.com> wrote in
> news:4089b966@newsgroups.borland.com:
> > IMHO, 'blocking components' are a bit of a kludge anyway since you
> > nearly always end up having to instantiate them in a thread class unless
>
> Lets not start this debate again - but blocking sockets are NOT a kludge.
If
> I had to choose one that was a kludge - it would be not blocking ones,
> espcecially if you look at history of sockets and why message based ones
were
> created under Windows.

<g> I said 'blocking components', not 'blocking sockets'.  I was referring
to visual components that, by themselves, block, like TidTCPClient.  I have
no problem with blocking sockets.

I apologise for not being clearer.

Rgds,
Martin

Chad Z. Hower aka Kudzu wrote:

>>Chad, are you talking about synchronous/asynchronous or 
>>blocking/non-blocking? Linux does support non-blocking sockets using 
>>ioctl(O_NONBLOCK)
> Yes, I mentioned then. They are "non blocking" but not the same as on 
> Windows. They are more like overlapped I/O.

non-blocking mode is the same on Windows and on Linux. It means only one 
thing - calls to certain functions (send, recv, select, accept, what 
else?) will return immediately with error EAGAIN (WSAEWOULDBLOCK) if 
they can't be performed. That's all.

> Yes, thats why I said threads/fork where forking on Unix is much more common, 
> alhtough threading is becoming quite common as well.

Hmm, I will re-phrase. It is not a good idea (despite it's common) to 
fork or to create threads. Using non-blocking sockets with select() is 
more effectie from performance point of view.

-- 
Eugene Mayevski
EldoS Corp., CTO
Security and networking solutions
http://www.eldos.com

"Eugene Mayevski [SecureBlackbox]" <mayevski@eldos.org> wrote in
news:408d7e2a$1@newsgroups.borland.com: 
> non-blocking mode is the same on Windows and on Linux. It means only one
> thing - calls to certain functions (send, recv, select, accept, what 
> else?) will return immediately with error EAGAIN (WSAEWOULDBLOCK) if 
> they can't be performed. That's all.

But require polling, they dont send Windows messages which is how they are 
normally used in Windows. Its very rare to use non blocking sockets in 
Windows without using Windows messages, unless you are using overlapped I/O.

> Hmm, I will re-phrase. It is not a good idea (despite it's common) to 
> fork or to create threads. Using non-blocking sockets with select() is 
> more effectie from performance point of view.

Yes it is - but forking and block remains the most common way to work under 
Unix for a variety of reasons. It is the "core" method and is not a hack by 
any venture as the original poster claimed.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

   Want to keep up to date with Indy?

   Join Indy News - it free!

      http://www.atozed.com/indy/news/

"Martin James" <mjames_falcon@dial.pipex.com> wrote in news:408d5192
@newsgroups.borland.com:
><g> I said 'blocking components', not 'blocking sockets'.  I was referring
> to visual components that, by themselves, block, like TidTCPClient.  I have
> no problem with blocking sockets.

There is not difference. Blocking components are simply object wrappers 
arounds the socket API.

The fact that TIdTCPClient is "visual" also has nothing to do with it. Its 
only visual at design time - its TComponent not a TControl. Its a pure RAD 
feature and does not use a Windowed control at runtime. Its no different than 
a TObject except that it has design time support in the IDE.

> I apologise for not being clearer.

There's no difference.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

   Got Indy? Got the book?

   http://www.atozed.com/indy/book/

"Eugene Mayevski [SecureBlackbox]" <mayevski@eldos.org> wrote in
news:408d7e2a$1@newsgroups.borland.com: 
> Hmm, I will re-phrase. It is not a good idea (despite it's common) to 
> fork or to create threads. Using non-blocking sockets with select() is 
> more effectie from performance point of view.

I shoudl also state that while on Windows IOCP is faster than blocking as 
well, it suffers the same problems as non blocking on Linux does and is the 
reason in most cases it is no used.

In short:
-Serialization
-Security
-Priority
-Ease of coding logic

In general blocking sockets are more than fast enough for 95% of the 
requirements, and in teh other 5% often the above requirement exclude the use 
of non blocking.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

  Is Indy useful to you? Send a postcard please!
  http://www.hower.org/kudzu/indypost.html

Chad Z. Hower aka Kudzu wrote:

> But require polling, they dont send Windows messages which is how they are 
> normally used in Windows. Its very rare to use non blocking sockets in 
> Windows without using Windows messages, unless you are using overlapped I/O.

No, they require using select(). In Windows this scenario is exactly the 
same. This is how we build most socket operations. Asynchronous Windows 
IO is unreliable and has some differences between documented and factual 
behaviour.

-- 
Eugene Mayevski
EldoS Corp., CTO
Security and networking solutions
http://www.eldos.com

"Eugene Mayevski [SecureBlackbox]" <mayevski@eldos.org> wrote in
news:408e168e@newsgroups.borland.com: 
> No, they require using select(). In Windows this scenario is exactly the

Yes, thats polling.

> same. This is how we build most socket operations. Asynchronous Windows 
> IO is unreliable and has some differences between documented and factual
> behaviour.

Async in Windows is implemented quite differently because it also support 
windows messages. Its very rare in Windows to do async and use select.

Select is also limited to 64 handles.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

   Need extra help with an Indy problem?

   http://www.atozed.com/indy/experts/

Chad Z. Hower aka Kudzu wrote:

> "Martin James" <mjames_falcon@dial.pipex.com> wrote in news:408d5192
> @newsgroups.borland.com:
> ><g> ............
>
> There is not difference. ...
>
> ...
>
> > I apologise for not being clearer.
>
> There's no difference.
>

Can't win with you, can he <BG>.


Alex

Chad Z. Hower aka Kudzu wrote:

> Select is also limited to 64 handles.

This is not a problem at all. One can use a threadl pool, each thread 
serving up to 64 connections (no matter client-side or server-side). In 
all cases this is more flexible than fork a thread for each connection.

-- 
Eugene Mayevski
EldoS Corp., CTO
Security and networking solutions
http://www.eldos.com

"Eugene Mayevski [SecureBlackbox]" <mayevski@eldos.org> wrote in 
news:408f59a4$1@newsgroups.borland.com:
> This is not a problem at all. One can use a threadl pool, each thread 
> serving up to 64 connections (no matter client-side or server-side). In 
> all cases this is more flexible than fork a thread for each connection.

It severely complicates the code and in most cases provides negligible 
benefit.

Its the same argument of IOCP (albeit its not as fast as IOCP) vs blocking in 
Windows.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

   Qualified help FAST with Indy Experts Support
   from the experts themselves:

   http://www.atozed.com/indy/experts/support.iwp

Chad Z. Hower aka Kudzu wrote:

> It severely complicates the code and in most cases provides negligible 
> benefit.

Which code? The code of the library? This is the problem of library 
developer, not user's problem. An all in all I can't see any problem 
with the code like

while not TerminateOperation do
   select(1, FSocket, nil, nil, 10);
if not TerminateOperation then
   read(FSocket...);

I don't think this (3 extra lines) severely complicates the code.
To make it clear: for experiments I turned our ElSSLIOHandler (and in 
this way indy itself) to completely non-blocking with about 10 or 15 
extra lines of code. Should one provide NonBlockingIOHandler for you to 
believe that this is NOT severely complicated?

-- 
Eugene Mayevski
EldoS Corp., CTO
Security and networking solutions
http://www.eldos.com

"Eugene Mayevski [SecureBlackbox]" <mayevski@eldos.org> wrote in 
news:408fdf4f$1@newsgroups.borland.com:
> Which code? The code of the library? This is the problem of library 
> developer, not user's problem. An all in all I can't see any problem 
> with the code like

Users code - the library cannot isolate them very much from a non blocking 
architecture.

> while not TerminateOperation do
>    select(1, FSocket, nil, nil, 10);
> if not TerminateOperation then
>    read(FSocket...);
> 
> I don't think this (3 extra lines) severely complicates the code.

Thats a very simplict example. You have no logic there. Its the same reason 
nearly all implementations are much less complex when implemented as blocking 
on Windows vs non blocking on Windows. No state machine is needed.

> To make it clear: for experiments I turned our ElSSLIOHandler (and in 
> this way indy itself) to completely non-blocking with about 10 or 15 
> extra lines of code. Should one provide NonBlockingIOHandler for you to 
> believe that this is NOT severely complicated?

Its a simple transport stream. These are rare.

Most users are writing servers with logic in them - that is a very big 
difference.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

   Want more Indy stuff? Try the Atozed Indy Portal at 
        http://www.atozedsoftware.com/
    * More Free Demos
    * Free Articles
    * Extra Support

"Eugene Mayevski [SecureBlackbox]" <mayevski@eldos.org> wrote in 
news:408fdf4f$1@newsgroups.borland.com:
> while not TerminateOperation do
>    select(1, FSocket, nil, nil, 10);
> if not TerminateOperation then
>    read(FSocket...);

This type is also on one socket - and since it calls select after on one 
socket its essentially a blocking model.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

   Want to keep up to date with Indy?

   Join Indy News - it free!

      http://www.atozed.com/indy/news/

Chad Z. Hower aka Kudzu wrote:

>>To make it clear: for experiments I turned our ElSSLIOHandler (and in 
>>this way indy itself) to completely non-blocking with about 10 or 15 
>>extra lines of code. Should one provide NonBlockingIOHandler for you to 
>>believe that this is NOT severely complicated?
> Its a simple transport stream. These are rare.
> Most users are writing servers with logic in them - that is a very big 
> difference.

Thi discussion is meaningless - you are so biased that you won't even 
think about adding non-blocking mode to Indym while people do need it.

-- 
Eugene Mayevski
EldoS Corp., CTO
Security and networking solutions
http://www.eldos.com

Chad Z. Hower aka Kudzu wrote:

>>while not TerminateOperation do
>>   select(1, FSocket, nil, nil, 10);
>>if not TerminateOperation then
>>   read(FSocket...);
> This type is also on one socket - and since it calls select after on one 
> socket its essentially a blocking model.

Really? Blocking more is when read() doesn't return until it completes 
the operation (or operation fails). From the code above you CAN'T 
conclude that it does so. The code above would work with non-blocking 
socket. Also, the above code lets you interrupt the operation without 
killing the socket from another thread.

-- 
Eugene Mayevski
EldoS Corp., CTO
Security and networking solutions
http://www.eldos.com

"Eugene Mayevski [SecureBlackbox]" <mayevski@eldos.org> wrote in 
news:409135b1$1@newsgroups.borland.com:
> Thi discussion is meaningless - you are so biased that you won't even 
> think about adding non-blocking mode to Indym while people do need it.

Thats crap - you havent looked at Indy 10 have you?

Its nothing to do with bias - your example was flawed.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

   Got Indy? Got the book?

   http://www.atozed.com/indy/book/

"Eugene Mayevski [SecureBlackbox]" <mayevski@eldos.org> wrote in 
news:40913877@newsgroups.borland.com:
> Really? Blocking more is when read() doesn't return until it completes 
> the operation (or operation fails). From the code above you CAN'T 
> conclude that it does so. The code above would work with non-blocking 
> socket. Also, the above code lets you interrupt the operation without 
> killing the socket from another thread.

Running a select immediately after a read is essentially blocking model of 
coding.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

  Is Indy useful to you? Send a postcard please!
  http://www.hower.org/kudzu/indypost.html

"Eugene Mayevski [SecureBlackbox]" <mayevski@eldos.org> wrote in 
news:40913877@newsgroups.borland.com:
>>>while not TerminateOperation do
>>>   select(1, FSocket, nil, nil, 10);
>>>if not TerminateOperation then
>>>   read(FSocket...);
>> This type is also on one socket - and since it calls select after on one 
>> socket its essentially a blocking model.


Aah I see the loop now. But now you are polling and using CPU. And you still 
have the problem of you are only using one socket here in this example and 
you have implemented a trivial task. 

Implementing a basic read versus implementing a real server is very different 
in complexity and how blocking vs non blocking works.

This simple example above can be done using Indy as is by selecting before 
hand too.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

   Need extra help with an Indy problem?

   http://www.atozed.com/indy/experts/

"Eugene Mayevski [SecureBlackbox]" <mayevski@eldos.org> wrote in 
news:409135b1$1@newsgroups.borland.com:
> Thi discussion is meaningless - you are so biased that you won't even 
> think about adding non-blocking mode to Indym while people do need it.

And even Indy 9 supports the basic type you sported here - Look at 
IdMappedPort for example and how it works.


--
Chad Z. Hower (a.k.a. Kudzu) - http://www.hower.org/Kudzu/
      "Programming is an art form that fights back"

   Qualified help FAST with Indy Experts Support
   from the experts themselves:

   http://www.atozed.com/indy/experts/support.iwp