kai@uicsrd.csrd.uiuc.edu (11/25/87)
I have modified the ReceiveMsg() routine in file screen.c of the virtual
terminal manager program "screen" to fix a problem that occured on one of our
machines, but could potentially occur on any UNIX machine. The problem
occurred when you were already running screen, and you tried to create a new
window by executing the command "screen <cmd>". The message area on the
bottom left side of the screen displayed "Short message (2048 bytes)", and
the command <cmd> was never executed. The source of the fix is included in
this posting.
As the article "A 4.2BSD Interprocess Communication Primer, Draft of July 19,
1984" states; "A Stream socket provides for the bidirectional, reliable,
sequenced, and unduplicated flow of data WITHOUT RECORD BOUNDARIES".
The original ReceiveMsg() routine expected all 2060 bytes sent from a
"client" screen pgm to a "server" screen pgm to make it over in one
write/read combination. Because stream sockets can not be relied upon to
maintain record boundaries, this is not always the case, so I changed it to
loop until all 2060 bytes are read (usually one or two tries).
I wrote a test client/server model to prove that UNIX domain stream sockets
work without record boundaries. The server loops waiting for connections,
then reading from the socket until EOF, reporting the size of each block
read. The client reads from standard input (up to a maximum of 8K blocks) and
writes exactly what it reads out to the socket, reporting the size of each
block read (and subsequently written).
The results were interesting. I ran the server on one window in screen, and
the client in another, so I could interactively compare the two program
results of block sizes. I tried "./client < file", where file was a 25K text
file, and client read and wrote three 8K blocks, and one fragment trailing
block. Server, however, read a mixture of 2K and 4K blocks. Running the same
test on a different brand system produced the same behaviour, but different
size blocks read. The code is available upon request.
Patrick Wolfe
pwolfe@kai.com
..!{uunet,ihnp4}!uiucuxc!kailand!pwolfe
Here is the fixed routine ReceiveMsg in file screen.c in it's entirety:
static ReceiveMsg (s) {
register ns;
struct sockaddr_un a;
int len = sizeof (a),
left;
struct msg m;
char *n;
if ((ns = accept (s, (struct sockaddr *)&a, &len)) == -1) {
Msg (errno, "accept");
return;
}
/*
* read variable size stream socket
* messages until the structure m is full
*/
n = (char *) &m;
left = sizeof (m);
while ((left > 0) && ((len = read (ns, n, left)) > 0)) {
left -= len;
n += len;
}
close (ns);
if (len == -1) {
Msg (errno, "read");
return;
}
else if (left > 0) {
Msg (0, "Short message (%d bytes)", len);
return;
}
switch (m.type) {
case MSG_CREATE:
ExecCreate (&m);
break;
case MSG_ERROR:
Msg (0, "%s", m.m.message);
break;
default:
Msg (0, "Invalid message (type %d).", m.type);
}
}
Patrick Wolfe
pwolfe@kai.com
..!{uunet,ihnp4}!uiucuxc!kailand!pwolfelwv@n8emr.UUCP (12/02/87)
Thanks for the bug fix for screen. We have several users who use it alot and so any bug fixes and enhancements are encouraged. Someone from Kentucky sent me a msg back in the summer saying that he had submitted quite a few changes to screen to comp.sources.someone and that if they didnt show up soon he would send me a copy personally. Well, I never got the mods either from the net or in email. If you have updates/enhancements/fixes with screen how about sending them to me? Thanks! P.S. I dont understand the screen option to save the termcap entry to a file. It doesnt seem to be much good, since the code doesnt use this file if it exists; at least, when I add some local variables used by our own software for additional function keys, and point TERMCAP to it and start up screen, the entries do not show up int he termcap entry. I end up having to set things up in my ENV file so that when I start a screen ksh up I get the new TERMCAP entry overriding the screen provided termcap entry. -- Larry W. Virden 75046,606 (CIS) 674 Falls Place, Reynoldsburg, OH 43068 (614) 864-8817 cbosgd!n8emr!lwv (UUCP) cbosgd!n8emr!lwv@ucbvax.Berkeley.EDU (BITNET) We haven't inherited the world from our parents, but borrowed it from our children.