Thread View: comp.sys.next.programmer
3 messages
3 total messages
Started by droux
Fri, 04 Sep 1992 14:32
TCP reliability on NeXT
Author: droux
Date: Fri, 04 Sep 1992 14:32
Date: Fri, 04 Sep 1992 14:32
94 lines
4308 bytes
4308 bytes
TCP/IP BERKELEY SOCKETS: Transmission problems with doublicated packets
-----------------------------------------------------------------------
We are currently implementing a distributed system providing the use of
different computers (different UNIX workstations) connected by Internet.
Our System is based on a server - client model using berkeley sockets.
These two entities are communicating through AF_INET family
sockets of SOCK_STREAM type. Our Problem is, that a receiver implemented on
a NeXT receives much more packets than the sender implemented on
a Sun workstation sends (1.3 : 1).
As TCP is known as sequenced, reliable and two-way connection based, this
fact is surprising to us. Is it possible to avoid this ?
We implemented the mechanism as follows:
OPERATING SYSTEMS:
NeXT Cube (System Release 2.1) and SUN Sparcstation 1+ (Sun OS 4.1)
CONNECTION:
a)Server side:
if ((socket_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) /* create sockets */
err_sys("client: error during socket creation");
our_bzero((char *) &sock_addr,sizeof(sock_addr));
sock_addr.sin_family = AF_INET; /* initializes socket addresses */
sock_addr.sin_port = 0;
sock_addr.sin_addr.s_addr = INADDR_ANY;
servlen = sizeof(struct sockaddr_in);
if (bind(socket_fd, (struct sockaddr *)&sock_addr, servlen))
err_sys("inet_bind_fix: error binding socket");
if (getsockname(socket_fd, (struct sockaddr *)&sock_addr, &servlen))
err_sys("inet_bind_fix: error getting socket name");
The port number is transferred using inetd to the client.
b)Client side:
if ((socket_fd = socket(AF_INET, SOCK_STREAM, 0)) < 0) /* create sockets */
err_sys("client: error during socket creation");
if ((foreign_addr = gethostbyname(machine)) == 0) /* get the server */
err_sys("unknown host");
our_bzero((char *) &sock_addr, servlen);
copy_struct(foreign_addr->h_addr,&sock_addr.sin_addr,
foreign_addr->h_length);
sock_addr.sin_family = AF_INET;
sock_addr.sin_port = htons(port);
do
{ /* connect to the power server */
connect_status = connect(socket_fd,
(struct sockaddr *)&sock_addr, servlen);
connect_retries--;
} while((connect_status < 0) && (connect_retries));
SOCKET OPTIONS:
#define SOCKET_BUFFER_LEN 10000 /* buffer size of a channel */
int buf_len = SOCKET_BUFFER_LEN; /* set new socket buffers length */
if (setsockopt(fd, SOL_SOCKET, SO_SNDBUF,
(char *)&buf_len, sizeof(buf_len)) == -1)
err_sys("set_sock_buf: cannot set new socket buffer length");
if (setsockopt(fd, SOL_SOCKET, SO_RCVBUF,
(char *)&buf_len, sizeof(buf_len)) == -1)
err_sys("set_sock_buf: cannot set new socket buffer length");
The data exchange is made by normal read() and write() calls followed by an
acknowledgement. We transmitt packets of 5000 bytes of unstructered data.
If a sender send 300 packets (as a concrete example) the receiver receives
over 400 packets and about 120 of them are invalid. We consider this as a
serious problem since our system is based on realibility of TCP sockets.
Is there a special option on sockets or another method to avoid these
problems?
Special Comments:
1. If the server and the client are running on the same computer, the problem
does not occur.
2. If the NeXT (receiver client) is swapping the number of faulty packets is
increasing.
3. The number of faulty packets is somehow depending on their size.
We would be very happy about some information as our application is part
of our graduation thesis.
Nicolas Droux & Daniel Liebhart
Biel School of Engineering, Switzerland
Computer Science Dpt.
E-mail: droux@hei.unige.ch
Re: TCP reliability on NeXT
Author: Thomas Funke
Date: Sat, 05 Sep 1992 11:42
Date: Sat, 05 Sep 1992 11:42
14 lines
1180 bytes
1180 bytes
In article <1992Sep4.163219.1@hei.unige.ch> writes: > > TCP/IP BERKELEY SOCKETS: Transmission problems with doublicated packets > ----------------------------------------------------------------------- NeXT TCP/IP (stream sockets) work fine on mixed networks. It's probably a bug in your application. Try to get "Unix Network programming" by W.R.Stevens. -- ------------------------------------------------------------------ Thomas Funke ** E-mail: thf@zelator.in-berlin.de NeXT-Developer * Unix-Consultant ------------------------------------------------------------------
Re: TCP reliability on NeXT
Author: Louis A. Mamakos
Date: Sat, 05 Sep 1992 13:57
Date: Sat, 05 Sep 1992 13:57
53 lines
2773 bytes
2773 bytes
In article <1992Sep4.163219.1@hei.unige.ch> droux@hei.unige.ch writes: > >TCP/IP BERKELEY SOCKETS: Transmission problems with doublicated packets >----------------------------------------------------------------------- You omitted the most interesting code of call: that which does read() and write(). >The data exchange is made by normal read() and write() calls followed by an >acknowledgement. We transmitt packets of 5000 bytes of unstructered data. >If a sender send 300 packets (as a concrete example) the receiver receives >over 400 packets and about 120 of them are invalid. We consider this as a >serious problem since our system is based on realibility of TCP sockets. >Is there a special option on sockets or another method to avoid these >problems? You are mistaken if you believe that TCP maintains any record boundaries when you preform a write() or read() system call. It does not. It is a stream protocol. When you perform a read() system call, it will return to you the number of octets of data returned to you which may be different than the size of your buffer. Thus, of the sending application writes 5000 bytes and the receiving application does a series of reads, it could return 3000 bytes on one read followed by 2000 bytes on a subsequent one. I am aware of no bugs in this area relating to TCP and the reliablity of the data being transmitted. >Special Comments: >1. If the server and the client are running on the same computer, the problem > does not occur. Of course it will act differently, as everything is effectively happening synchronously since you are never leaving the machine. >2. If the NeXT (receiver client) is swapping the number of faulty packets is > increasing. Again, probably timing related. >3. The number of faulty packets is somehow depending on their size. How do you know the "packet" are faulty? Remember, the user interface to TCP has no notion at all of "packets", just streams of data. It is very similar to a tty-type device in that respect. >We would be very happy about some information as our application is part >of our graduation thesis. You should investigate a very good book: "UNIX Network Programming" by Stevens. It covers this material quite well. louie
Thread Navigation
This is a paginated view of messages in the thread with full content displayed inline.
Messages are displayed in chronological order, with the original post highlighted in green.
Use pagination controls to navigate through all messages in large threads.
Back to All Threads