SCOUG Logo


Next Meeting: Sat, TBD
Meeting Directions


Be a Member
Join SCOUG

Navigation:


Help with Searching

20 Most Recent Documents
Search Archives
Index by date, title, author, category.


Features:

Mr. Know-It-All
Ink
Download!










SCOUG:

Home

Email Lists

SIGs (Internet, General Interest, Programming, Network, more..)

Online Chats

Business

Past Presentations

Credits

Submissions

Contact SCOUG

Copyright SCOUG



warp expowest
Pictures from Sept. 1999

The views expressed in articles on this site are those of their authors.

warptech
SCOUG was there!


Copyright 1998-2024, Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.

The Southern California OS/2 User Group
USA

SCOUG-General Mailing List Archives

Return to [ 31 | October | 1999 ]

<< Previous Message <<


Date: Sun, 31 Oct 1999 08:52:02 PDT
From: Peter Skye <pskye@peterskye.com >
Reply-To: scoug-general@scoug.com
To: scoug-general@scoug.com
Subject: SCOUG-General: TCP/IP questions

Content Type: text/plain

David LaRue wrote:
>
> Hello Peter,

Hi, David, :)

> >1. How many sockets am I allowed to have open?
>
> ... Unless you are considering creating more
> than say 100, this should not be a problem.
> They do use resources which will bog down your
> system. Consider this in your design as well.

Good point. I'll have to do some testing to see what, say, 200 open
sockets will do to the system.

> >2. If the socket buffer becomes full, what
> > happens to new data received by TCP/IP?
>
> Datagram sockets (UDP) will be lost ...
>
> Stream sockets (TCP) will preserve the consistancy
> of the stream. There are negotiations between the
> sender and receiver ... in the smaller acknowledgement
> packets that are sent back to the sender.

Okay, thanks. With 200 open sockets and data coming in on all of them,
it's possible that a thread won't be able to service its buffer before
the buffer is completely filled. Since I don't want to delay the
transmission of the data (by TCP/IP telling the sender that it can't
accept more data momentarily), I'll add a separate thread to each socket
that will move the socket buffer contents to a larger storage buffer.

> ... the sender cannot release its copy of the
> data until the receiver (all levels) have
> replied that the data has been transfered.

Always wondered how that worked. :)

> >3. I know I can set socket options to
> > increase the receive buffer size. What's
> > the maximum size I can make this buffer?
>
> ... TCP/IP/Ethernet may all have different
> settings. A 4096 byte TCP packet ...

Sorry I wasn't clear on this last one. I meant the size of the memory
buffer where the socket data is kept, not the size of the packets.
There are two programming calls, setsockopt() and getsockopt(), which
allow you to set up the socket any way you like. I want to make the
buffers fairly large so I can do a round-robin service of all sockets
and have plenty of buffer space available in case it takes a while
before I get back to any particular socket.

David, thanks for the info.

- Peter

=====================================================

To unsubscribe to this list, send an email message
to "steward@scoug.com". In the body of the message,
put the command "unsubscribe scoug-general".

For problems, contact the list owner at
"rollin@scoug.com".

=====================================================


<< Previous Message <<

Return to [ 31 | October | 1999 ]



The Southern California OS/2 User Group
P.O. Box 26904
Santa Ana, CA 92799-6904, USA

Copyright 2001 the Southern California OS/2 User Group. ALL RIGHTS RESERVED.

SCOUG, Warp Expo West, and Warpfest are trademarks of the Southern California OS/2 User Group. OS/2, Workplace Shell, and IBM are registered trademarks of International Business Machines Corporation. All other trademarks remain the property of their respective owners.