Augusto,
The UniRPC protocol hanging when contacted by other network protocols
working on the same TCP port is not exactly what we could name a "bug".
But, for the very true reasons you exposed, enhancements have been made in
UniRPC daemon ("unirpcd" executable) to handle smoothly the case of
unexpected packets causing the daemon to hang, as the UniRPC "applicative"
protocol doesn't know about any of the others high-level protocols such as
"telnet", "ftp", and so on.
A new "unirpcd" parameter = -timeout tt, with "tt" in seconds allows the
UniRPC daemon to handle smoothly this situation.
We recommend the timeout value to be the smallest as your network can
support, because for the duration of the timeout, the UniRPC daemon is
actually hanging, but in a controlled manner, and no more UniRPC
connections can be accepted.
A value of 15 seconds seems generally the largest acceptable value on most
sites, so it could be reduced on purpose.
Note that this parameter exists for UniVerse on Windows platform starting
at release 10.1.23 for releases 10.1.x and 10.2.3 for releases 10.2.x.
The procedure to get it enabled through Windows Services Manager is
documented in the "patchlist" file accessible on :
https://www-927.ibm.com/software/data/u2/support/u2techconnect/downloads/readme/UV-10.1.23.zip
Have to look at "Issue # 9074".
On UNIX platforms, the "-timeout" parameter was altready existing in the
early releases 10.0.x (and UniData 6.0.x), (and it's much easier to have it
enabled at system command line !).
Hope this will help.
P.S: The answer here is one more reason to attend to U2U in IBM Bedfont
Lakes (Feltham) as my manager suggested !...
Regards,
Herve' Balestrieri
> Hi all.
>
> If you do a telnet against any Universe server on port 31438 (I have
tested
> it on Universe 10.0.10 in Windows, Universe 10.0.20 in Linux and Universe
> 10.0.6 in HP-UX), you will have something very similar to a Denial Of
> Service on this port 31438:
> - all previous UVRPC established sessions keep on working without
> problem, but
> - any subsequent tries to start new UVRPC sessions, will timeout with
> "Error returned from connect = 81015".
>
> The problem desappears when the PC client closes the telnet session. (Or
you
> can restart UniVerse or the whole server...)
>
> Could someone tell me if is it a normal behaviour or is it a unirpcd bug?
> Is there any way of detect or avoid this kind of sessions?
> Could it be the same problem that some viruses (like Blaster) causes on
> UVRPC of Universe Servers?
>
> Any help will be apreciated.
>
> Regards,
> ______________________________
> Augusto Alonso Alonso
> IT Manager
> Quiter Servicios Informaticos S.L.
> [EMAIL PROTECTED]
> www.quiter.com
> ______________________________
-------
u2-users mailing list
u2-users@listserver.u2ug.org
To unsubscribe please visit http://listserver.u2ug.org/
