L
lecuyer
Guest
One thing to keep in mind wrt server sockets is that the server socket "listening" behavior (i.e. waiting for CONNECT events) is tied to the avm event processing. that is, once the socket server is properly set up , the application has to call WAIT-FOR() or PROCESS-EVENTS(). While processing the WAIT-FOR(), if a socket event occurs (i.e. a client connects), it causes the CONNECT event procedure to run. This becomes trickier inside an appserver agent, which is only active while running a remote procedure call from a client. That is, it is not running any ABL code between handling RPC calls. It is possible to create a socket server inside an agent, but it must happen inside a client RPC call. Given that, the WAIT-FOR() must necessarily complete in order for the remote procedure call to return to the client. This means that the appserver agent cannot act as a socket server in the sense that it will accept and process events *between* rpc calls. This limits its usefulness somewhat in this environment. The exception to this was the classic webspeed agent. The normal "idle state" of a classic webspeed agent was Inside a WAIT-FOR statement in the webspeed web-disp.p. The agent essentially waited on a WAIT-FOR() for web events. As such, it was possible to set up a server socket that could respond to socket events while the agent was between web calls. It should be noted that in the PASOE environment, the web interface is supported in the agent using the appserver rpc model (ie. it does NOT use the WAIT-FOR semantics, except as described above). Therefore, in PASOE, you cannot run the same kind of socket server as in the classic webspeed agent.
Continue reading...
Continue reading...