Thread View: comp.os.os2.programmer
3 messages
3 total messages
Started by Claudius Chlebosch
Wed, 03 Apr 1991 21:34
Problems with IBMs TCP/IP V1.1 for OS/2
Author: Claudius Chlebosch
Date: Wed, 03 Apr 1991 21:34
Date: Wed, 03 Apr 1991 21:34
43 lines
2788 bytes
2788 bytes
I got some problems with IBMs TCP/IP V1.1 for OS/2 using stream sockets an i hope to get some help on this way. I have to write a program, which transfers data using stream sockets in portions of 32 kByte. The sender should send this portions with one call to the send() function and the receiver should get this portions with one call to the recv() function. This works very well, if the size of the transmitted segments does not exceed about 6000 bytes and only one segment is transferred using the same socket. In the other case the receiving program has to call the function recv() several times to get the complete segment. Normally the recv() function should block the process, until the whole segment is reveived. For example: the client calls send() with the msgLen set to 20000. The server calls the recv() function, which blocks the process, until the whole 20000 bytes are received. The client calls send() once again with the msgLen set to 20000. The server calls the recv() function, which returns with 4360 bytes received. The client has to call the recv() function once again to get the remaining 15640 bytes of the segment. In my opinion this behaviour is not correct. second problem: If the server an the client reside in the same machine, no fragmentation is detected, if the size of the transmitted segments is less than the receivebuffersize (which is 23360 bytes as reported by the function getsockopt() ). This beviaour does not change, even if the receivebuffersize of the receiving socket and the sendbuffersize of the sending socket are increased via the setsockopt() call. The border at which fragmentation begins remains at 23360 bytes. My configuration is: two IBM PS/2 (mod 80 and mod 50Z) both with an Token-Ring adaptercard 16/4 A and OS/2 1.2 EE CSD:4098 and TCP/IP V1.1 for OS/2 (Program number: 5798-RXW Part Number : 66F5612). The mtu parameter of the TCP/IP is set to 4400 as it is recommended in the documentation. I hope somebody can give me a hint how i can solve this problem. Thanx for reading this message. Klaudius Chlebosch -- Klaudius Chlebosch | usenet: ..chlebosc@nadia.stgt.sub.org Eschenweg 1 | Mailbox: *49 711 484464 24 h 1200/2400 Baud D-7045 Nufringen | *49 711 461592 24 h 1200/2400 Baud Tel.: *49 7032 82023 |
Re: Problems with IBMs TCP/IP V1.1 for OS/2
Author: Joe Herman
Date: Thu, 04 Apr 1991 20:02
Date: Thu, 04 Apr 1991 20:02
24 lines
1457 bytes
1457 bytes
In article <ZSNPX4T@nadia.stgt.sub.org>, chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) writes: > I have to write a program, which transfers data using stream sockets in > portions of 32 kByte. The sender should send this portions with one call > to the send() function and the receiver should get this portions with > one call to the recv() function. It sounds like what you want to do is write and read a 32KB *record*. Since you created a *stream* socket, the data you send will arrive as a stream of bytes and it's up to you to put it together as a record. > The server calls the recv() function, which returns with 4360 bytes received. > The client has to call the recv() function once again to get the remaining > 15640 bytes of the segment. In my opinion this behaviour is not correct. It may not be the functionality you want, but it is the correct behavior. Joe Herman U. of Maryland dzoey@terminus.umd.edu -- "Everything is wonderful until you know something about it."
Re: Problems with IBMs TCP/IP V1.1 for OS/2
Author: mikem
Date: Fri, 05 Apr 1991 01:27
Date: Fri, 05 Apr 1991 01:27
21 lines
1727 bytes
1727 bytes
In article <ZSNPX4T@nadia.stgt.sub.org> chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) writes: >I got some problems with IBMs TCP/IP V1.1 for OS/2 using stream sockets an i >hope to get some help on this way. > >I have to write a program, which transfers data using stream sockets in portions >of 32 kByte. The sender should send this portions with one call to the send() >function and the receiver should get this portions with one call to the recv() >function. No. You can *not* code your client program to expect that a block of bytes sent by your server will arrive in a single receive. It doesn't matter what TCP/IP implementation you use. To do so is to cripple your client. What you need to do is place some sort of signature byte so that your client knows when the data block is complete and can process that block at that time. Michael R. MacFaden IBM Palo Alto Marketing Systems mikem@ibmpa.awdpa.ibm.com, macfaden@paloic1.vnet.ibm.com disclaimer: what I write above is not necessarily my employer's opinion
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