SYSLOG uses port 514 on UDP
RSH uses port 514 on TCP

I reported some time ago that the TCPIP utility corrupts records when
you try to create 2 separate entries, one for TCP-514 and one for
UDP-514 (you can manually fix this and it then works).

Had to reboot the system for the first time since I had fixed that, (due
to NFS hanging) and I found out that while SYSLOG and RSH started, RSH
just didn't get any calls. Both are started by the kernel (aka: defined
in the TCPIP services database).

shutting down RSH and restarting it made it work.

The SYSLOG code seems to do:
sd_syslog = socket(AF_INET, SOCK_DGRAM, 0);
....
service_ent = getservbyname("syslog", "udp");
....
socket_name.sin_family = AF_INET;
socket_name.sin_port = service_ent->s_port;
socket_name.sin_addr.s_addr = 0;
....
bind(
sd_syslog,
(struct sockaddr *) &socket_name,
sizeof(socket_name)) < 0)

Based on the abbreviated above code, is it correct to assume that
SOCK_DGRAM will only cause that program to listen to UDP calls ?




Question:


If the SYSLOG code tried to listen to both UDP and TCP, would the TCPIP
kernel allow RSH to take over 514-TCP or would an error be issued ?

(aka: RSH starts, then SYSLOG starts and "steals" 514-TCP from RSH, and
when you restart RSH, RSH then steals 514-TCP from SYSLOG).

Or is there very strict protection against one service stealing
listening sockets from another ?

Has anyone experienced similar problems in the past ? Once it is started
it seems to work fine.