Quantcast

Implementing a Server

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Implementing a Server

Eduardo
Hello,

I am planning to replace a legacy server with a QServer based one, but for not affecting the current client applications I need to keep two features that the legacy server requires for stablishing connections:

1) The server must accept a identification string for the incoming connections before accepting messages, this is something similar to the required in another thread (commit r2714) but viewed from the other end of the wire.

2) The server must accept two connectios for a single client, one for incoming messages and the other for outgoing messages. The type of connection is defined in the identification string.

The identification string is also used for control and monitoring the connection state of multiple clients connected to the same channel. I know, this last thing needs some work on my side, afortunally at this stage is not required =).

Please give some advice on how to achive point 1 and 2. Thanks in advance.

Regards
Eledu
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Implementing a Server

Mark Salter-5

eledu 81 wrote:

>
> I am planning to replace a legacy server with a QServer based one, but for
> not affecting the current client applications I need to keep two features
> that the legacy server requires for stablishing connections:
>
> 1) The server must accept a identification string for the incoming
> connections before accepting messages, this is something similar to the
> required in another thread (commit r2714) but viewed from the other end of
> the wire.
>
> 2) The server must accept two connectios for a single client, one for
> incoming messages and the other for outgoing messages. The type of
> connection is defined in the identification string.
Is the identification string unique to each client and is it this value
that links the two separate connections (in/out) as a pair?

Are the ports distinct for each role - probably not important, I just
wondered.

Are both connections long lived, handling multiple messages?

Is there an enforced logical order in which a pair of connections is
established, how about closed?

>
> The identification string is also used for control and monitoring the
> connection state of multiple clients connected to the same channel. I know,
> this last thing needs some work on my side, afortunally at this stage is not
> required =).

So something will monitor the status of a connection pair via an
interface of some sort, but this interface is not needed at?

--
Mark

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Implementing a Server

Eduardo
Hi Mark,

Is the identification string unique to each client and is it this value
that links the two separate connections (in/out) as a pair?

Are the ports distinct for each role - probably not important, I just
wondered.

The identification string contains a code for identifying a unique entity (institution/client), mostly (if not always) is two connections per entity: one for incoming messages and the other for outgoing messages, both on the same port, two sockets actually. Also the id string contains a value for diferentiate what socket connection is incoming or outgoing.

There is a third type of connection for mixed connections, incoming and outgoing messages in the same socket.. but that is easy for jPOS so no problem with that.

Are both connections long lived, handling multiple messages?

The conections are long lived, if the connection is not long lived we usually use the third type of connection: mixed.

Is there an enforced logical order in which a pair of connections is
established, how about closed?

There is no logical order for the connections, when both sockets are connected and sends its corresponding id string, the state of the entity(institution/client) becomes connected. If one socket is loss the state becomes disconnected (there is more intermediates states, but it is not important right now)

So something will monitor the status of a connection pair via an
interface of some sort, but this interface is not needed at?

Yes, we have a application for monitoring the state of the connections of all entities. Also from this application you can stop, reset, start, echo the connection of one entity. The system also collect info for all entities, for example, if one connection/entity have a max number of malformed messages the connection is closed, etc.

The monitoring stuff will be needed sometime, but I think is something doable building some modules (I hope).  I am worried more about the connection problem.

---
Regards
Eledu

2009/3/30 Mark Salter <[hidden email]>

eledu 81 wrote:

>
> I am planning to replace a legacy server with a QServer based one, but for
> not affecting the current client applications I need to keep two features
> that the legacy server requires for stablishing connections:
>
> 1) The server must accept a identification string for the incoming
> connections before accepting messages, this is something similar to the
> required in another thread (commit r2714) but viewed from the other end of
> the wire.
>
> 2) The server must accept two connectios for a single client, one for
> incoming messages and the other for outgoing messages. The type of
> connection is defined in the identification string.
Is the identification string unique to each client and is it this value
that links the two separate connections (in/out) as a pair?

Are the ports distinct for each role - probably not important, I just
wondered.

Are both connections long lived, handling multiple messages?

Is there an enforced logical order in which a pair of connections is
established, how about closed?

>
> The identification string is also used for control and monitoring the
> connection state of multiple clients connected to the same channel. I know,
> this last thing needs some work on my side, afortunally at this stage is not
> required =).

So something will monitor the status of a connection pair via an
interface of some sort, but this interface is not needed at?

--
Mark




--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Implementing a Server

Alejandro Revilla

May I ask the rationale of doing this dual-socket thing?


--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

Re: Implementing a Server

Eduardo
It is a legacy application (10+ years in production, vos-cobol). I suspect that the limitations with x25 its the reason for this mess; then, when we migrated to tcp/ip (few years ago), we decided to keep this scheme to minimize impact(testing, documentation, certifications). We still have channels in x25 by the way, mostly with banks.

I am planning to move a little part of the application to jPOS as a proof of concept.

---
Eledu

2009/3/30 Alejandro Revilla <[hidden email]>

May I ask the rationale of doing this dual-socket thing?





--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

AAO
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

RE: Implementing a Server

AAO

You’ve caught my attention with that “vos cobol” reference.

 

A similar experience to share:  We converted a large Stratus Continuum customer to jPOS-fueled goodness.  As part of the process, we used it as an opportunity to get all X.25-based legacy stuff like that out of picture.  The customer is very much happier being mainstream in all facets of their operation.  Standard jPOS MUXes and channel management meet our needs completely.

 

Every bank and association we talked to for that project jumped at the opportunity to convert to TCP/IP.  YMMV, but it never hurts to ask.

 

Andy Orrock

 

From: [hidden email] [mailto:[hidden email]] On Behalf Of eledu 81
Sent: Monday, March 30, 2009 5:56 PM
To: [hidden email]
Subject: Re: Implementing a Server

 

It is a legacy application (10+ years in production, vos-cobol). I suspect that the limitations with x25 its the reason for this mess; then, when we migrated to tcp/ip (few years ago), we decided to keep this scheme to minimize impact(testing, documentation, certifications). We still have channels in x25 by the way, mostly with banks.

I am planning to move a little part of the application to jPOS as a proof of concept.

---
Eledu

2009/3/30 Alejandro Revilla <[hidden email]>


May I ask the rationale of doing this dual-socket thing?






--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "jPOS Users" group.
To post to this group, send email to [hidden email]
To unsubscribe from this group, send email to [hidden email]
For more options, visit this group at http://groups.google.com/group/jpos-users?hl=en
-~----------~----~----~----~------~----~------~--~---

Loading...