Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 505
  • Last Modified:

Are Indy components based on blocking sockets?


  hi experts,

       Delphi Indy components are based on blocking sockets. Why they are designed as blocking sockets style.
 
               Can you please explain me.
0
inampudi1
Asked:
inampudi1
4 Solutions
 
twocandlesCommented:
Here you have Indy team explanation:

http://www.swissdelphicenter.ch/en/showarticle.php?id=4
0
 
HypoCommented:
Yes,
Indy components are based on blocking sockets, and my guess why they are is that blocking sockets is actually easier and offer a much more robust way of working with network communication than what non-blocking sockets do.

A couple of years ago I worked for a company on quite a large application that was using non-blocking sockets (It was using the native VCL TServerSocket/TClientSocket) to communicate with different modules over TCP/IP. It worked fine most of the time, but sometimes I would run into problems; like for instance when I had to have a two way communication from within a function in my code, where the response from the clients would influence how the function would react next; and the Event based messaging just forced my function to be transformed into some kind of state machine, where variables in my code had to keep track of waht state the communication with the clients where in for different functions. If the application would have used blocking sockets, then I could have just written my function straight up, but with the non-blocking sockets it was just not possible to do in a good way.

When I used Indy for the first time after that experience, it became clear to me how much easier my work would have been if they had used blocking sockets instead of non-blocking sockets.

Sure, It's faster to start working with non-blocking sockets in a GUI-application, since it fit's the whole event based structure, and that the application itself don't freeze when it waits for a response; also, using blocking sockets require that you know thread programming quite well, and are used to doing good exception handling, but if you do know these stuff, then I think you will see that in the long run, when the communication becomes a little bit more advanced than just sending and receiving simple messages, there are benefits of using blocking sockets over non-blocking.

regards
Hypo
0
 
MerijnBSr. Software EngineerCommented:
With Hypo,

I just want to add that (imho) the choice between blocking and non-blocking really depends on what kind of data you are going to transmit. If it's a protocol where a response from a client has influence on what to do next (like Hypo describes), blocking is surely the better option. In other cases non-blocking is easier to grasp (and thus better).
I find that I tend to design my protocol designs in such a way that I can use them with non-blocking sockets, just because I like working with non-blocking so much better.

Personally I use ICS when working with non-blocking sockets: http://www.overbyte.be/frame_index.html
0

Featured Post

Receive 1:1 tech help

Solve your biggest tech problems alongside global tech experts with 1:1 help.

Tackle projects and never again get stuck behind a technical roadblock.
Join Now