|
Depends on the application, how it was written, what its requirements are, etc. A few ways to handle multiple sockets that I've used: 1) Put the socket descriptors into an array. Use nonblocking sockets and the select() API to multitask between all of the connected sockets. Naturally, this means you have to keep track of different states for every connection, different variables for each one, etc. This makes for a complicated program, but it works nicely for 1-100 sockets or so. 2) Submit a new job for each client that connects. You can prestart 5-10 jobs, and have them waiting on data queues, or on the takedescriptor() API, so your client won't have to wait for the job startup time. (mine wait on data queues so I can do a timeout, then check SHUTDN, then go back to waiting) This is the same type of approach that IBM uses for the FTP server, and I think also for the http server (though they may have changed the way that works) 3) Have your RPG program just deal with one client at a time. (Depending on the requirements of the application, this might be the best solution) Naturally a poorly designed application will be a bottleneck, but I don't think it particularly matters which language the poorly designed application is written in :) On Wed, 11 Apr 2001, Nathan M. Andelin wrote: > > How many simultaneous connections does an RPGLE-socket interface support? > Most socket servers are written in C and use threads to support multiple > concurrent conversations. Wouldn't an RPG socket server be a bottleneck? > > Just asking. Thanks, Nathan. > +--- | This is the Midrange System Mailing List! | To submit a new message, send your mail to MIDRANGE-L@midrange.com. | To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com. | To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com. | Questions should be directed to the list owner/operator: david@midrange.com +---
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.