🚀 go-pugleaf

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