I concur. Exposing select at the Unicon level is the way to go. This will get you your
timeout but also gets the important functionality of waiting for more than one handle
to have activity and being able to include the passive socket handle with the active
ones to accept new connections. There are simply too many types of applications that
are too painful to write if you don't have a select function. A Unicon level version
of select should probably use a "Unicon set" or possible just a table of socket
handles which would then get morphed into the C array of handles. There is a little
bit of cross platform madness to deal with in that the WinSock flavor of select
doesn't let you mix socket handles with any other flavor of handles like pipes windows
etc. like you can on Unix systems. These platform differences should be hidden behind
the implementation of the Unicon level select so that it always works the same at the
Unicon level. A brief list of differences between Winsock and "REAL Berkeley sockets"
is quoted below.
------------------------
- In Winsock, the type of a socket is a Win32 handle, not a POSIX file descriptor.
That means that you cannot read from / write to a socket using the _read() / _write()
function, nor can you adjust its settings with ioctl, nor can you close a socket using
_close.
- For a Winsock socket s, (s < 0) does not necessarily mean that s has an invalid
value.
- The Winsock version of the select() function can monitor I/O events on sockets only;
the Winsock select() does not work with consoles, pipes, windows, or anything other
than sockets.
- A Winsock socket is also a somewhat non-standard Win32 handle. You can read from /
write to a Winsock socket using the Win32 functions ReadFile / WriteFile. You cannot
close a Winsock socket, however, using CloseHandle. FYI, the proper way to close a
socket is with the closesocket() function. Moreover, a Winsock socket cannot be used
in Win32 API functions such as WaitForMultipleObjects that could be used as a
substitute for select().
--------------------------
All together now ... Ugh! ...
-----Original Message-----
From: Shamim Mohamed [mailto:[EMAIL PROTECTED]
Sent: Wed 6/23/2004 5:32 PM
To: Robert Parlett; Unicon group
Cc:
Subject: Re: [Unicon-group] Timeouts on sockets
Robert Parlett suggests:
>1) Add an optional extra parameter to the open() call when "n" is the option,
>which would specify the timeout; for example
> sock := open("www.google.com:80", "n", 10)
>would fail after about 10 seconds on a timeout, in which case &errno would be
>set to EINTR - this would allow a timeout to be distinguished from other
>causes of failure.
It would be nice to have a connect timeout.
>2) Add a timeout parameter to the sysread() call, which does low-level i/o on
>a file; for example
> str := sysread(sock, 1024, 10)
>would specify a timeout of 10 seconds; &errno to be set as before.
Anything beyond what select() already does?
L := select(sock, 10)
if *L > 0 then
str := sysread(sock, 1024)
The whole sysread thing is a lousy hack and I wish we could get rid of
it. (Not too hard: the runtime should not use stdio for file operations
-- it should do its own I/O buffering as appropriate. Then read would
automatically do the right thing.)
>3) Add a new function to mirror sysread, syswrite, which would include
timeout
>functionality :-
> syswrite(sock, str, 10)
What would you use syswrite for? (A file can be put into non-blocking
mode with fcntl.)
-s
-------------------------------------------------------
This SF.Net email sponsored by Black Hat Briefings & Training.
Attend Black Hat Briefings & Training, Las Vegas July 24-29 -
digital self defense, top technical experts, no vendor pitches,
unmatched networking opportunities. Visit www.blackhat.com
_______________________________________________
Unicon-group mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/unicon-group
N¬HS^µé[)¢{(ç[ÈZrAÚâyø§Äëj)â