"Enquiring Mind" <Enquiring.Mind@nospam.btopenworld.com> wrote in message
news:488da0b6$1@newsgroups.borland.com...
> Am I right in thinking that the first operating system to conceive
> and implement sockets as the basis for inter-computer communication
> was Unix
Yes - specifically, Berkeley Unix.
> and that Microsoft subsequently created Winsock as an essentially
> compatible port of the Unix model to the Windows platform
Actually, Microsoft did not implement the first WinSock. Back in Windows
3.0, third-party apps had to provide their own socket stacks. It wasn't
until Windows 3.x that Microsoft started building its own into the OS.
> but couldn't resist adding Windows-specific features to something
> that should be kept non-platform-specific?
Microsoft didn't have much of a choice in that matter. As I explained
earlier, blocking sockets would not have worked very well in the Windows 3.x
environment. Non-blocking features had to be added to the API in order for
sockets to even be feasible. When Windows 95 was released, blocking sockets
could then be used effectively. But Microsoft has continued to carry on,
and even to expand on, its non-blocking features as well.
> Since the Mac OS is based on Unix are its sockets facilities
> more or less compatible with those of the original Unix?
Just about everyone's socket capabilities are mostly compatible with the
original socket API - even Microsoft's.
> I only have Delphi 7. Where can I find the unit containing the
> TClientSocket and TServerSocket components?
They are in the "ScktComp" unit.
> That seems to confirm my previous comment that there are no major
> advantages in using non-blocking sockets if the code is to be portable
> to Windows and Unix.
Portable code, no. But if you are not worried about portability, then there
is no reason now to use non-blocking features if they are available.
> The WSAEventSelect approach seems to be much more consistent
> with that of I/O through the serial port using WaitForMultipleObjects
WSAEventSelect() and WSAWaitForMultipleObjects() were introduced in Winsock
2.0 when Microsoft added support for overlapped I/O and completion ports to
WinSock.
> So could it be argued that the need for non-blocking sockets is obsolete?
Not necessarily. WinSock's overlapped I/O support provides for better
server scalability. With blocking sockets, you would usually need to have 1
thread per client connection. That is the model Indy servers currently use.
If you have a lot of clients connected at one time, that is a lot of
individual threads running. Eventually, you will reach OS limitations in
how many concurrent clients you can handle effectively. With non-blocking
and overlapped I/O, on the other hand, you can mimimize the number of
threads needed, and better optimize the threads you do have for the number
of CPUs that are present.
Gambit
