Re: OTSndOrderlyDisconnect
Re: OTSndOrderlyDisconnect
- Subject: Re: OTSndOrderlyDisconnect
- From: Roger Persson <email@hidden>
- Date: Wed, 09 Jul 2003 14:24:21 +0200
Okay, it helps me alot. However, you gave some suggestion and more
questions. :-)
Can I cancel the OTSndDisconnect()/shutdown() request orginated from the
client, depending on how the server response. I searching for the minimal
load on servers, and requests from clients will in , say 3 of 4 cases,
result in a busy response from the server.
The sample code "OT Virtual Server" says the the server can receive a
T_ORDREL and the result of OTRcvOrderlyDisconnect() may be a
kOTNoDisconnectError, and the disconnect should be ignore.
I'm still in the learning phase so any tip would be appricated.
Thanks,
Roger P.
<email@hidden> wrote:
>
At 22:28 +0200 6/7/03, Roger Persson wrote:
>
> can I call OTSndOrderlyDisconnect when I know my connection will only
>
> receive data and not send any more?
>
>
Yes.
>
>
> Is there any advantages?
>
>
There may be, depending on how your client/server model is structure.
>
If your server supports lots of clients, its better if the clients
>
call OTSndOrderlyDisconnect (or the BSD sockets equivalent,
>
shutdown(fd, 1)) rather than the server. This distributes the
>
FINWAIT (or is that FINWAIT2???) load amongst the clients, rather
>
than having them all concentrated on the server.
>
>
However, the most important thing is that you must conform to the
>
protocol specification you're using. To wit...
>
>
> How do other servers understand this? Do they send the request or disconnect
>
> the connection immediately?
>
>
That depends on what protocol the servers speak. For example, the
>
HTTP protocol specifies the following sequence.
>
>
1. client opens connection
>
2. client sends request
>
3. server sends response
>
4. server starts disconnect
>
5. client confirms disconnect
>
>
If you're implementing HTTP, you have to follow this sequence.
>
>
[It would be a lot nicer to busy HTTP servers if the specification
>
had required the following sequence.
>
>
1. client opens connection
>
2. client sends request
>
3. client starts disconnect
>
4. server sends response
>
5. server confirms disconnect
>
>
However, that's not how it works.]
>
>
In summary, from a TCP perspective it's fine if you start a
>
disconnect after sending all of your data but before receiving all of
>
the response. If you're designing your own protocol from scratch,
>
you should probably try to do that. However, if you're implementing
>
an existing protocol, you have to follow the rules specified by the
>
protocol.
>
>
S+E
_______________________________________________
macnetworkprog mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/macnetworkprog
Do not post admin requests to the list. They will be ignored.