chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) (04/04/91)
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 |
oleg@watson.ibm.com (04/05/91)
In <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. > This works very well, if the size of the transmitted segments does not exceed ab > 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 proce > until the whole segment is reveived. No, it is not how recv()/send() work. You can't make any assumptions on size of segments that you get with recv(). Also, there is 8K per call limit on send/recv in OS/2 TCP/IP implementation. [TEXT DELETED] > 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. What do you mean by fragmentation, and what is the problem here ? [TEXT DELETED] > Klaudius Chlebosch | usenet: ..chlebosc@nadia.stgt.sub.org Oleg Vishnepolsky
dzoey@umd5.umd.edu (Joe Herman) (04/05/91)
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."
mikem@ibmpa.awdpa.ibm.com (04/05/91)
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
colin@la.excelan.com (Colin Goldstein) (04/06/91)
The News Manager) Nntp-Posting-Host: la Reply-To: colin@la.novell.com (Colin Goldstein) Organization: Novell, Inc., San Jose, Ca References: <ZSNPX4T@nadia.stgt.sub.org> Date: Thu, 4 Apr 1991 16:17:06 GMT In article <ZSNPX4T@nadia.stgt.sub.org> chlebosc@nadia.stgt.sub.org (Claudius Chlebosch) writes: >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. > I don't have the IBM TCP/IP package, but the TCP/IP toolkit from Novell works the same way. Although stream sockets give reliable delivery, there is no way to be sure that all the data will arrive at the same time. It is therefore the applications responsibility to recv() until all the data is read. Keep a count of bytes read or use select() to determine if more data is available. Colin -- /-------------------------------------------------------------------\ | The views expressed here are my own. | Norm, what are you | | They do not necessarily represent | up too??? | | the views expressed by my employer. | | | ---------------| My ideal weight if I | | colin@novell.com | Novell Inc., | were 11 feet tall. | | uunet!novell!colin | San Jose | - Cheers | \-------------------------------------------------------------------/