RE: [U2] Socket API problem
Nick, Would device licensing be useful in your environment? We have device licensing and with this all outside connections from the same IP address only consume 1 license. We use this scenario to have several uniobject clients (java servlets and applications) run from a server and therefore only using one license per machine rather than per process. Jeff On Thu, 2007-08-02 at 08:46 -0400, Nick Cipollina wrote: > All of your suggestions are very good, the problem is that all of these > solutions will introduce too much overhead. I know that a lot of the > overhead is very, very minimal, but we cannot afford ANY overhead at > all. > > Thanks, > > Nick Cipollina > > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Craig Bennett > Sent: Thursday, August 02, 2007 6:38 AM > To: u2-users@listserver.u2ug.org > Subject: Re: [U2] Socket API problem > > Hi Nick, > > I don't have an answer to your licensing problem, but have you > considered running your listener from inetd or a similar superserver? > > In this setup your inetd daemon (or service on windows) listens on your > known port, when a request comes in the superserver starts a UV process > to handle the incoming request (received on stdin so get the data with > INPUT or GETS) send your response using print. > > This is slightly slower per request than prestarting all your phantoms > but you only use as many licences as your peak load and if you have one > of the more advanced inetd versions you can limit the maximum number of > simultaneous requests (other requests will be queued by inetd). > > > I have implemented a HTTP server using this setup and other than the uv > licensing cost it works well. > > > regards, > > > Craig > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ > > > CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is > for the sole use of the intended recipient(s) and may contain confidential > and privileged information. Any unauthorized review, use, disclosure, or > distribution is prohibited. If you are not the intended recipient, please > contact the sender by reply e-mail and destroy all copies of the original > message. > --- > u2-users mailing list > u2-users@listserver.u2ug.org > To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Socket API problem
As the only problem seems to be the licensing method, I think I would try to engage IBM to see what the options are. Perhaps a per processor license could be worked out. -- Don Kibbey --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Socket API problem
Nick, Do you have to have synchronous communications or can you get by with stale messaging? If you can packetize the data in your protocol, then check out the MVWWW core. (http://mvwww.sourceforge.net) I gave up, long ago, on MV socket processing and decided to go with a file I/O architecture when writing this HTTP service replacement for . The clients (in this case CGI applications), contact a spooler via socket and then the spooler drops a request file into a queue directory. The spooler then waits for a certain amount of time for a response file or returns a wait error if no response is seen. The file spooling is structured like this: /spool/ /spool/requests/ /spool/responses/ You can stop and start MV phantoms as you need to handle the load without affecting live processing. I was working on a load manager, but pressing engagements have taken me away from development. Each phantom opens the /spool/ path, does a readnext for the ID, locks it, deletes it, and then reads the request from /spool/requests/. After deleting the request and processing it, the response is written to /spool/responses/ and processing goes back to the top. The C spooler code needs some tweaking, but you may be able to take this architecture and implement a spooler in a different way. Glen Batchelor --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Socket API problem
Don't know how UV license works. Sorry. How about Phantom a listener after you accepts a client connection? Yeah.. sure... there is a cost of starting a new phantom job... Because the listener cannot fork (of course, you can use UNIX domain socket to pass a socket descriptor to a new phantom process... but that will require C programming.) like C text book socket server examples, PHANTOM the listener may be the easiest way to go... That was just my 2 yen. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Cipollina Sent: Wednesday, August 01, 2007 9:38 PM To: u2-users@listserver.u2ug.org Subject: [U2] Socket API problem Hello All, We are currently stuck at version 10.1 of Universe because IBM has changed what causes a UV license to be consumed. In versions 10.1 on older versions, phantom processes do not require a separate universe license. As of version 10.2, this is no longer the case. Phantom processes will require a user license in order to run. This is a problem for us, because we currently run thousands of phantom processes to process transactions, real-time. Now you may say, well it is only fair that you should have to pay for each of these processes because they are essentially the same thing as a user session. We are interacting with the data through these phantoms. The reason we have to run so many processes is because of how Universe has implemented the socket API. Here is how I'm hoping someone on the list might be able to help me, or correct me on my understanding of how the socket API works. If my understanding is correct, the universe socket API does not allow the listener to pass of the socket connection to another process for processing and response. The process that is listening on a port and accepts the connection, is also the process that must answer. This is not typically how a socket service works. Typically, you have a process listening on a port, and when you receive a connection, the connection is passed off to another process for processing and response. So, unless my understanding of how this works is incorrect, we have to run so many phantoms because the Universe socket API is not set up to handle multiple connections on a single port. We actually have an F5 load balancer that accepts the connections on a single port and passes it off to one of the many phantoms that is listening on a unique port. I have two questions: 1. Is there anyone out there that is in the same boat we are? Is anyone else stuck on version 10.1 or older because they cannot afford to upgrade to 10.2 because of the licensing requirements? 2. Is my understanding of how the universe socket API works correct? If so, has anyone come up with a way around this limitation? Keep in mind, we currently process 95% of our transactions in 1/10th of a second. Thanks, Nick Cipollina MCTS, MCP ACS Heritage, Inc. 2810 North Parham Road, Suite 210 Richmond, VA 23294 (804) 965-8294 CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Socket API problem
All of your suggestions are very good, the problem is that all of these solutions will introduce too much overhead. I know that a lot of the overhead is very, very minimal, but we cannot afford ANY overhead at all. Thanks, Nick Cipollina -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Craig Bennett Sent: Thursday, August 02, 2007 6:38 AM To: u2-users@listserver.u2ug.org Subject: Re: [U2] Socket API problem Hi Nick, I don't have an answer to your licensing problem, but have you considered running your listener from inetd or a similar superserver? In this setup your inetd daemon (or service on windows) listens on your known port, when a request comes in the superserver starts a UV process to handle the incoming request (received on stdin so get the data with INPUT or GETS) send your response using print. This is slightly slower per request than prestarting all your phantoms but you only use as many licences as your peak load and if you have one of the more advanced inetd versions you can limit the maximum number of simultaneous requests (other requests will be queued by inetd). I have implemented a HTTP server using this setup and other than the uv licensing cost it works well. regards, Craig --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Socket API problem
Hi Nick, I don't have an answer to your licensing problem, but have you considered running your listener from inetd or a similar superserver? In this setup your inetd daemon (or service on windows) listens on your known port, when a request comes in the superserver starts a UV process to handle the incoming request (received on stdin so get the data with INPUT or GETS) send your response using print. This is slightly slower per request than prestarting all your phantoms but you only use as many licences as your peak load and if you have one of the more advanced inetd versions you can limit the maximum number of simultaneous requests (other requests will be queued by inetd). I have implemented a HTTP server using this setup and other than the uv licensing cost it works well. regards, Craig --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
RE: [U2] Socket API problem
Hi Nick - Phantoms do not take a licence in uv - only 'interactive phantoms' - an interactive phantom is one that uses the socket api or its derivatives (http and soap api's) - This is of course no use to you. What can be done is change the architecture slightly - so you have your core listener on a known port, when it receives a request from a client it gets the next free port from a pool and starts a phantom listening on that port, and passes back to the client the new port. The client then disconnects and reconnects to the new port. You will still have multiple licences in use but only for the clients that are connected. Or radically change it to use a messaging layer - i.e. write webservices for the functions you want to do using uniobjects.net etc or the u2 soap stuff, and then have your clients connect to them. You can use connection pooling this way and configure your number of connections etc in the web server and pooling parameters. This will also take advantage of device licencing. After years of writing my own socket based apps this is now very much my preferred way of doing things. HTH Symeon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Cipollina Sent: 02 August 2007 02:38 To: u2-users@listserver.u2ug.org Subject: [U2] Socket API problem Hello All, We are currently stuck at version 10.1 of Universe because IBM has changed what causes a UV license to be consumed. In versions 10.1 on older versions, phantom processes do not require a separate universe license. As of version 10.2, this is no longer the case. Phantom processes will require a user license in order to run. This is a problem for us, because we currently run thousands of phantom processes to process transactions, real-time. Now you may say, well it is only fair that you should have to pay for each of these processes because they are essentially the same thing as a user session. We are interacting with the data through these phantoms. The reason we have to run so many processes is because of how Universe has implemented the socket API. Here is how I'm hoping someone on the list might be able to help me, or correct me on my understanding of how the socket API works. If my understanding is correct, the universe socket API does not allow the listener to pass of the socket connection to another process for processing and response. The process that is listening on a port and accepts the connection, is also the process that must answer. This is not typically how a socket service works. Typically, you have a process listening on a port, and when you receive a connection, the connection is passed off to another process for processing and response. So, unless my understanding of how this works is incorrect, we have to run so many phantoms because the Universe socket API is not set up to handle multiple connections on a single port. We actually have an F5 load balancer that accepts the connections on a single port and passes it off to one of the many phantoms that is listening on a unique port. I have two questions: 1. Is there anyone out there that is in the same boat we are? Is anyone else stuck on version 10.1 or older because they cannot afford to upgrade to 10.2 because of the licensing requirements? 2. Is my understanding of how the universe socket API works correct? If so, has anyone come up with a way around this limitation? Keep in mind, we currently process 95% of our transactions in 1/10th of a second. Thanks, Nick Cipollina MCTS, MCP ACS Heritage, Inc. 2810 North Parham Road, Suite 210 Richmond, VA 23294 (804) 965-8294 CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
Re: [U2] Socket API problem
Hi, Have you considered the use of pipes for inter-process communication. Also, on UNIX/Linux, semaphores provide a powerful way to synchronise/trigger processes. It's also possible to use an http server like Apache to achieve very similar functionality as one would with sockets, i.e if you have control over the application that is establishing a connection to a socket, modify it to communicate via http and tools like FastCGI to maintain persistent processes. If you'd like to discuss this off-line please feel free to email me directly Regards Ian Stuart Nick Cipollina wrote: Hello All, We are currently stuck at version 10.1 of Universe because IBM has changed what causes a UV license to be consumed. In versions 10.1 on older versions, phantom processes do not require a separate universe license. As of version 10.2, this is no longer the case. Phantom processes will require a user license in order to run. This is a problem for us, because we currently run thousands of phantom processes to process transactions, real-time. Now you may say, well it is only fair that you should have to pay for each of these processes because they are essentially the same thing as a user session. We are interacting with the data through these phantoms. The reason we have to run so many processes is because of how Universe has implemented the socket API. Here is how I'm hoping someone on the list might be able to help me, or correct me on my understanding of how the socket API works. If my understanding is correct, the universe socket API does not allow the listener to pass of the socket connection to another process for processing and response. The process that is listening on a port and accepts the connection, is also the process that must answer. This is not typically how a socket service works. Typically, you have a process listening on a port, and when you receive a connection, the connection is passed off to another process for processing and response. So, unless my understanding of how this works is incorrect, we have to run so many phantoms because the Universe socket API is not set up to handle multiple connections on a single port. We actually have an F5 load balancer that accepts the connections on a single port and passes it off to one of the many phantoms that is listening on a unique port. I have two questions: 1. Is there anyone out there that is in the same boat we are? Is anyone else stuck on version 10.1 or older because they cannot afford to upgrade to 10.2 because of the licensing requirements? 2. Is my understanding of how the universe socket API works correct? If so, has anyone come up with a way around this limitation? Keep in mind, we currently process 95% of our transactions in 1/10th of a second. Thanks, Nick Cipollina MCTS, MCP ACS Heritage, Inc. 2810 North Parham Road, Suite 210 Richmond, VA 23294 (804) 965-8294 CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/ ___ DISCLAIMER ___ This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a hard-copy version. ___ DISCLAIMER ___ This message contains confidential information and is intended only for the individual named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail. Please notify the sender immediately by e-mail if you have received this e-mail by mistake and delete this e-mail from your system. E-mail transmission cannot be guaranteed to be secure or error-free as information could be intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender therefore does not accept liability for any errors or omissions in the contents of this message, which arise as a result of e-mail transmission. If verification is required please request a h
[U2] Socket API problem
Hello All, We are currently stuck at version 10.1 of Universe because IBM has changed what causes a UV license to be consumed. In versions 10.1 on older versions, phantom processes do not require a separate universe license. As of version 10.2, this is no longer the case. Phantom processes will require a user license in order to run. This is a problem for us, because we currently run thousands of phantom processes to process transactions, real-time. Now you may say, well it is only fair that you should have to pay for each of these processes because they are essentially the same thing as a user session. We are interacting with the data through these phantoms. The reason we have to run so many processes is because of how Universe has implemented the socket API. Here is how I'm hoping someone on the list might be able to help me, or correct me on my understanding of how the socket API works. If my understanding is correct, the universe socket API does not allow the listener to pass of the socket connection to another process for processing and response. The process that is listening on a port and accepts the connection, is also the process that must answer. This is not typically how a socket service works. Typically, you have a process listening on a port, and when you receive a connection, the connection is passed off to another process for processing and response. So, unless my understanding of how this works is incorrect, we have to run so many phantoms because the Universe socket API is not set up to handle multiple connections on a single port. We actually have an F5 load balancer that accepts the connections on a single port and passes it off to one of the many phantoms that is listening on a unique port. I have two questions: 1. Is there anyone out there that is in the same boat we are? Is anyone else stuck on version 10.1 or older because they cannot afford to upgrade to 10.2 because of the licensing requirements? 2. Is my understanding of how the universe socket API works correct? If so, has anyone come up with a way around this limitation? Keep in mind, we currently process 95% of our transactions in 1/10th of a second. Thanks, Nick Cipollina MCTS, MCP ACS Heritage, Inc. 2810 North Parham Road, Suite 210 Richmond, VA 23294 (804) 965-8294 CONFIDENTIALITY NOTICE: This e-mail message, including any attachments, is for the sole use of the intended recipient(s) and may contain confidential and privileged information. Any unauthorized review, use, disclosure, or distribution is prohibited. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. --- u2-users mailing list u2-users@listserver.u2ug.org To unsubscribe please visit http://listserver.u2ug.org/
