hjpark@kaist.UUCP (HyeonJe Park) (12/03/84)
We have connected two 4.2BSD with serial I/O routines from Harvard. Operations using TCP(or stream socket) work well, but operations using UDP(or datagram socket) - talk, rwho, dsh - do not work. If the size of data to receive is large, the local machine seems not to get the data from the remote machine. In case of the command rwho, it works well only when the remote machine has up to nine users. It does not receive at all if more than nine users. Does anyone out there have this problem? Has someone fixed it? Park, Hyunje KAIST, Seoul Korea (UUCP: ...!hplabs!kaist!hjpark)
chris@umcp-cs.UUCP (Chris Torek) (12/05/84)
> We have connected two 4.2BSD with serial I/O routines from Harvard. > Operations using TCP(or stream socket) work well, > but operations using UDP(or datagram socket) - talk, rwho, dsh - > do not work. If the size of data to receive is large, > the local machine seems not to get the data from > the remote machine. In case of the command rwho, > it works well only when the remote machine has up to nine users. > It does not receive at all if more than nine users. I don't know why you'd have problems with talk or dsh, but rwho uses broadcast UDP packets, and these are not allowed to fragment. We weren't sure why this was so -- perhaps to reduce the load on anyone receiving uninteresting broadcast packets -- but we went ahead and removed the restriction, and things work fine. The restriction is in sys/netinet/ip_output.c, where you will find a set of lines looking something like this: /* don't allow broadcast messages to be fragmented */ if (ip->ip_len > ifp->if_mtu) { error = EMSGSIZE; goto bad; } If you simply remove this check, the kernel will merrily fragment broadcast messages, and you can ``rwho'' with a practially infinite number of users. (Whether you can run anything else with as many users is an entirely different question.) -- (This line accidently left nonblank.) In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (301) 454-7690 UUCP: {seismo,allegra,brl-bmd}!umcp-cs!chris CSNet: chris@umcp-cs ARPA: chris@maryland