Clarifying socket handle and server socket handle functionality - Forum - OpenEdge Development - Progress Community

Clarifying socket handle and server socket handle functionality


Clarifying socket handle and server socket handle functionality

This question is not answered

I'm trying to clarify an ambiguity in the docs - there's reference to a server socket object and a socket object - do these two objects overlap in terms of functionality?

I would expect them to be different in terms of configuration and enabling, and have commonality in terms of sending and receiving data. 

The docs don't make that clear - the server socket docs have this:

  • NAME attribute,
  • HANDLE attribute,
  • NEXT-SIBLING attribute,
  • PREV-SIBLING attribute
  • PRIVATE-DATA attribute,
  • SENSITIVE attribute
  • TYPE attribute




  • CONNECT event

While the socket docs have 

  • BYTES-READ attribute
  • BYTES-WRITTEN attribute
  • HANDLE attribute
  • LOCAL-HOST attribute
  • LOCAL-PORT attribute
  • NAME attribute
  • NEXT-SIBLING attribute
  • PREV-SIBLING attribute
  • PRIVATE-DATA attribute
  • REMOTE-HOST attribute
  • REMOTE-PORT attribute
  • SENSITIVE attribute
  • SSL-SERVER-NAME attribute
  • TYPE attribute


  • CONNECT( ) method (Socket object)
  • CONNECTED( ) method
  • DISCONNECT( ) method (Handle)
  • GET-SOCKET-OPTION( ) method
  • READ( ) method (Socket)
  • SET-SOCKET-OPTION( ) method
  • WRITE( ) method (Socket)

Some of the socket functionality could apply to server sockets, others clearly do not. Which is which isn't clear. 

All Replies
  • 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.

  • Ah yes!!  Thank you Peter.  Now I remember this.

  • jmls

    one of the advantages of using a class to create a socket is that you can use the destructor to delete the socket handle - as a handle is not garbage collected.

    What I'd really like to see is the various dynamic objects OO-ized. Memory issues - gone! OO technology - enabled! 


  • You needn’t bother with the client socket (unless you absolutely must have your own implementations).
    There are a set of classes for Client Socket support in the - OpenEdge.Net.ServerConnection.ClientSocket and friends ( ).
  • Cool! I'll look into that.

  • And BTW - The doc seems to be all correct on this - Each method correctly indicates what object it can be used on and the doc on SERVER-SOCKET vs. SOCKET IMO clearly indicates what each is used for.  For example, there is a note under SERVER-SOCKET that says: "The server socket object is used to enable the AVM to listen to and accept new connections from socket clients; it is via the socket object that clients and servers communicate"

    You're problem seems to have been that what you were reading didn't jive with your a priori conceptions so you didn't trust what it said!  :-)

  • Laura - I'd note that 13 years ago I spent ~2 months sorting through the socket docs to get a communications protocol working under 9.1, and while I was able to get something working and in production, it had data-loss issues at higher throughput that I couldn't resolve. Even today it seems there've been details I've missed - like when I'm in the READ-RESPONSE routine that SELF points to an endpoint socket object and not the server socket object. 

    Was it my fault for failing to "get" that rather critical piece of information after 2 months of work? Or PSC doc's for failing to make it completely clear that an operational system had both a server and an endpoint socket? 

    Had "socket object" been termed a "socket endpoint object" and the statement edited accordingly - 

    it is via the socket endpoint object that clients and servers communicate

    The difference / distinction between the two would've been a lot clearer. 

    Re: the data loss issue - I later learned that I needed to set hserversocket:SENSITIVE to FALSE in the READ-RESPONSE code...something I can't recall ever seeing in the docs. Also, back when I was first wrestling with this there wasn't even any demo code around to look at - the community had to figure all this out for themselves.

  • In addition - the socket KBs need to link to these classes - not much point in writing your own if something else already is out there.

  • In some ways, I think that the language distinction between "socket" and "server socket" is part of the confusion.  I'm guessing that this distinction derives, in part, from the way that tcp network implementations are expressed in object models.  The ABL concept (although handle based) is consistent with the way sockets are done in Java (and probably in many other languages as well).  However, if you look at the C implementation of TCP, there really isn't much a difference.  When you can create a socket, its "type" (client or server) is based the way it is used, with the distinction being mainly in how the connection is made with the remote peer.  However, once connected, a socket is a socket.  In some ways, it's harder to see the difference, but in other ways, simpler.  Just my $.02.

  • That’s a good point – I don’t  know in general terms what we do when kbases go ‘stale’.
  • > On Jul 10, 2017, at 1:05 PM, Peter Judge wrote:


    > I don’t know in general terms what we do when kbases go ‘stale’.