Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.sys.acorn.programmer > #6063

Re: Socket limits

Show all headers | View raw

In message <r7ld1j$fn3$1@dont-email.me>
          druck <news@druck.org.uk> wrote:

> On 20/04/2020 19:25, Alan Adams wrote:
>> Each client has 3 sockets - one to broadcast a request for the server, one
>> to listen to incoming data, and one to send data to the server. The server
>> uses one broadcast, and one listen, plus one send socket per client.

> [Snip]

> Why do you need a send and receive socket? A single TCP socket can do
> both, you can even send out of band data to implement asynchronous
> notifications.

Thanks for the comments. It's helped me clarify what actually happens.

I've just trawled my way through the part of the code I wrote about ten 
years ago to handle connections.

The listen socket listens for broadcast data. Not all of the applications 
need it, so there's one easy saving I can make.

It's used for those applications where there must not be two copies 
running anywhere across the network. When one of those starts up it 
broadcasts a message effectively sayinf "are you there". Any pre-existing 
copy will reply. If the new copy wants to take over, it sends a "quit" 
message to the earlier copy, which shuts down. This allows control to be 
passed to a different computer for example.
If it doesn't want to take over, it simply quits.

>> I think I can reduce my socket usage by creating the broadcast sockets
>> when needed and deleting them afterwards. That will need some testing of
>> course. It's not just the initial connection that uses them - if a
>> connection drops or times out, the system attempts to reconnect
>> automatically.

> The clients broadcast socket can be created only when needed. Once
> you've sent a broadcast to identify the server, you should be able to
> reconnect to the same address after that.

I think it will be fairly easy to create the broadcast socket as needed. I 
just need to check how easy it is to delete it cleanly after use. 
Alternatively I think I would need to record the server address and 
listen-port number to send the announcement that starts the reconnection.

I'm now at a good point to look at these changes, as I've eliminated a 
long-standing bug that, at apparently random times, caused a disconnection 
followed by an inability to reconnect. It came down to the difference 
betweeen IF K%<0 and IF K%<=0.

> If you really need more clients, consider switching to UDP rather than
> TCP, as the sever can receive data from any number of clients on a
> single socket. You can chuck around far more data with UDP, but you have
> to take care of the integrity yourself.

I've had another look at socketwatch, and I don't think I need a separate 
bit in the mask for each client. That seems to be used to allow the poll 
return to identify quickly which socket needs servicing. I'm scanning them 
all, so it shouldn't be needed.

In normal use, I expect to need somewhere just over 20 clients across the 
network at a time. The socketwatch limitation I thought existed, would 
have made that a bit marginal.

The socket limit of 96 would only apply in the unusual case of running all 
the clients on one computer. This would only occur during testing.


> ---druck


-- 
Alan Adams, from Northamptonshire
alan@adamshome.org.uk
http://www.nckc.org.uk/

Back to comp.sys.acorn.programmer | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread

Thread

Socket limits Alan Adams <alan@adamshome.org.uk> - 2020-04-20 19:25 +0100
  Re: Socket limits Paolo Fabio Zaino <p.zaino@zfpsystems.com> - 2020-04-20 16:03 -0700
  Re: Socket limits druck <news@druck.org.uk> - 2020-04-21 00:59 +0100
    Re: Socket limits Alan Adams <alan@adamshome.org.uk> - 2020-04-21 15:39 +0100
      Re: Socket limits Alan Adams <alan@adamshome.org.uk> - 2020-04-22 12:59 +0100

csiph-web