KR20000033268A - Multicast communicating device and method using corba - Google Patents

Abstract

PURPOSE: A multi cast communicating device and method using CORBA is provided for supporting stream transmission of multi session, multi cast and multimedia, for efficiently controlling the multi cast connection in a communicating network, and modulating to have additional function expansion and modification. CONSTITUTION: A multi cast communicating device using CORBA has a right for the multi cast connection, requests the connection control including the multi cast connection setting and releasing, and comprises of: a user object requesting a data stream transmission control; a connection administrator controlling a source and a destination administrators with administrating the multi cast connection by the request from the user object; a source administrator administrating the destination device handler by the control of the connection administrator; and a source device handler and a destination device handler supporting the data stream transmission between the source device and the destination device by the controls of the source device and the destination device, respectively.

Description

Multicast communication apparatus and method using CORBA

The present invention relates to a multimedia data service, and more particularly, to an apparatus and method for multicast communication using CORBA, which efficiently supports multimedia stream data transmission and supports multicast and multisession.

Multicasting means delivering information from one source to specific destinations, and broadcasting means transmitting to all receivers. Multicast groups have a predefined, centrally managed closed group of recipients and an open group where recipients can join the group arbitrarily. Applications that require multicasting often establish point-to-point connections between each source and group member. When a source sends data, it replicates and exports each connection. In fact, some applications work by connecting multiple ISDN or X.25 circuits.

In general, there are two types of applications that support multicast. One is StreamWorks and RealAudio, which provide multicasting capabilities at the application level. This is how the transmitting program delivers data to each receiving program. In this method, because the amount of information processing of the sending computer is large and the same data is repeatedly transmitted to each receiving program through the network, network bandwidth is wasted so much that the receiving program cannot be embraced. The other is IP multicast and Mbone (Multicast Backbone), which provide multicasting at the network level. This is a field currently being studied as an alternative to eliminate the disadvantage that the methods described in the former cannot efficiently transmit data.

The technical problem to be achieved by the present invention is to support multi-session, multicast connection management independent of the underlying network, to manage the establishment and release of multicast connection, to support the transmission of multimedia streams and to efficiently manage the multicast connection in a computer communication network The present invention provides a multicast communication apparatus and method using CORBA that is modular and flexible for easy function expansion and function change.

1 illustrates a configuration of a network for efficiently providing various communication services in the future.

2 shows the functional structure of the CSM.

3 shows the functional structure of an SM.

4 illustrates a call related object constituting one service.

5 shows an example of a communication configuration.

6 is a block diagram of a multicast communication apparatus using CORBA according to the present invention.

7 illustrates a process in which a user joins a group and establishes a connection in order to receive a multimedia service.

8 is a diagram illustrating a process of starting a stream transmission using a group ID (gid) received from the connection manager C after joining a group and establishing a connection.

9 shows a process in which a user object Ug joins a group in which a current session is open.

10 illustrates a process of starting a stream transmission for a newly subscribed member to receive a service.

FIG. 11 illustrates an operation in which a member who does not use a service among members who are subscribed to the group leaves the group.

12 is for explaining disconnection.

In order to solve the above technical problem, a multicast communication apparatus using CORBA according to the present invention has ownership of a multicast connection, requires connection control including at least multicast connection establishment and release, and controls data stream transmission. Requesting user object; As an object of CORBA, a connection manager that supports multisession and multicast, manages a multicast connection according to a request from the user object, and controls a source manager and a destination manager; An object of CORBA, the source manager managing a source device handler under the control of the connection manager; An object of CORBA, the destination manager managing a destination device handler under the control of the connection manager; A source device handler which controls a source device by management of the source manager to support a stream transmission of data between the source device and the destination device; And a destination device handler which controls the destination device by management of the destination manager to support the stream transmission of data between the source device and the destination device.

In order to solve the above technical problem, a multicast communication method using CORBA according to the present invention includes a user, a connection manager, a source manager and a destination manager as distributed objects for multisession and multicast, Connecting the signal via CORBA communication using; And when a signal is connected between the source and the destination through the signal connection, transmitting data using a socket. For the signal connection, the user is an object used for an administrator to set up a necessary task in the entire connection process, and the connection manager manages a multicast connection at the request of the user and the source manager and the destination manager. The source manager and the destination manager manage each device handler under the control of the connection manager as an object that abstracts the source and the destination of the multicast connection. A device handler is provided for the data transmission, and the device handler is connected to a source and a destination and controls a multimedia device to support connection establishment and transmit data.

Hereinafter, the present invention will be described in detail with reference to the accompanying drawings. 1 illustrates a configuration of a network for efficiently providing various future communication services. There are users, service providers, and network elements, which make up three networks. The three networks include a transport network (TN: 100) for data transmission between users, a service control network (SCN: 110) to provide service control capability, and a management network for management of network elements. (TMN: Telecommunication Management Network, 120).

The service control network 110 provides a function for controlling a service to a user. Since such networks exist independently, various users can negotiate during the call setup process. Even when a call is established and a connection is provided, a new connection setup, a change of connection attributes, and a release of some connections may be required. In practice, one channel of the transport network may be used as a service control channel. Conceptually, however, it exists as a separate network, which can be seen as an extension of the current signaling network.

The service control network 110 accepts the user's requirements and delivers them to the service manager 112, and also informs the user of the current call status. Call session management (CSMF) Function, 114) element. This functional element represents a user and allows negotiation between users through cooperation with the SCF (Service Control Function) of the service manager 112 and the counterpart CSMF 114 to communicate with. The CSMF 114 may be regarded as adding a function of an intelligent network and a function of notifying a user of an event occurring in the network.

The service manager 112 containing the service logic is connected to both the service control network 110 and the management network 120, and has a service control function (SCF) 116 element and a lower network resource for controlling the service. The resource management function (RMF: Resource Management Function, 122) element in charge of the management function for can be separated.

The service control function (SCF) 116 may need to be performed before the actual connection is established, or may be performed after the call is released or after the connection is activated. For example, among the current intelligent network services, such as call forwarding should be performed before the actual connection is established, and the service that informs the result of resource usage and billing should be released when the call is released. In the case of adding a new party, services such as confirmation procedure should be performed during communication. Inform the call establishment request before the connection establishment, and proceed with negotiation between users. If such variables are set through the negotiation process, the service manager 112 is notified of this, and the service manager 112 uses the RMF 122 to provide the actual connection between users using the lower network resources.

The management function to be performed by the service manager 112 is a function of a service management layer of a telecommunication management network (TMN) 120. Therefore, this is performed by looking at the lower network as a whole in the case where the functions of the element management layer of the TMN 120 and the network management layer of the transport network are provided.

1. Functional model of each element

1.1 Features of the Call Session Manager (CSM)

The CSM exists between the user 130 and the SM 112, and provides an interface for requesting or modifying a service to the user 130, and also notifies the user of status information of the network received from the SM 112. Do it. Therefore, CSM must have access CSMF function. It performs functions such as user authentication and location management.

A user must be bound to one CSM to receive services from the network. The connection between the user 130 and the CSM may be established at all times, or only when necessary. In case of setting only when necessary, meta signaling for establishing a connection between the user and the CSM is required before the user receives the service.

In addition, a CSM supporting one user may be fixed or may vary. In a wired network in which the mobility of a user or a terminal is not provided, a CSM tied to one user is fixed. However, when mobility is provided, the CSM tied to mobility varies.

Location management of a user required in a mobile communication network can also be interpreted as an operation between the user and the CSM. If the CSM is fixed, information on user authentication, service usage rights, service environment variables, etc. can be maintained and related tasks can be performed. If the CSM is not fixed, elements that maintain this information should be accessed, related information obtained, and processed based on it. Such information may be maintained in the SM 112, or may be maintained in a CSM uniquely set for each user.

Signaling CSMF function is required to exchange service control message between CSM and SM. In the present invention, OMG CORBA is used as the protocol between CSM and SM. In addition, although not considered in the present invention, there may be several SMs accessible to the CSM for usability, overcoming failure, or distributed processing, and routing SCMF for exchanging route information therebetween. May be present.

To receive the user's request to the SM 112, and to inform the user of the current service status based on the information received from the SM 112, an Object Manager CSMF function is required. This includes the creation and deletion of call-related objects, the ability to return when requesting information about an object's properties, the get of an object's properties, and the reporting of events occurring in the object. There are functions such as report. The call-related objects maintained by these CSMs contain only the portion of the call objects that must be shown to the user who supports them. 2 shows the functional structure of the CSM.

1.2 SM Functions

The service manager 112 provides a service to the user 130 based on the service control of the user, the state change of the network, and the service logic. When the user creates a call object through the CSM and specifies the destinations and resources to be used through their attribute values, the SM 112 delivers them to the destination CSMs to inform the user of the intention and negotiate between users. Let's proceed. After this negotiation process, the actual connection is provided through matching the call objects with the functions and resources of the transport network. 3 shows the functional structure of an SM.

1.3 Functions of RMF

The service manager 112 must accept the user's request for the call and determine whether to provide or deny it. This requires the total amount of resources held by each network element in its area, the amount allocated to the currently set calls, the total amount of available resources, and the status information about the network status. The function of the RMF 122 may be regarded as performing a service management function and a network management function of the TMN 120.

2. Call Object Model Supporting Multimedia Application Services

To specify a call, the parties of the call, the connections for providing communication services between them, the nature of the data they carry, and the various relationships between calls, parties, and connections Should be able to express

A call object, which means a service, is the parent node of the objects that are associated with it. Thus, objects representing parties, connections, and relationships belonging to this arc become child nodes of the arc object. Attributes that a call object must have include a unique call identifier within the entire network, and other information such as the number of connection or relationship objects belonging to the call.

The party object attached as a child node of the call object contains dynamic information of service users participating in the call. Static information about a user's service can exist as a separate object, and the party object mentioned here has a reference to the object containing that information. The identifier of the party object may be directly used for identifying the service user in the network, or may be separately provided. The function to get the physical address for the actual connection based on the identifier of the party object is called when establishing the actual connection. The property of the party object may include references to the connection objects to which the party will participate, the number of connection objects, etc., in addition to the object reference containing the party identifier and fixed user information mentioned above.

Connection objects represent the various types of connections that the call will use. At this time, the connection is a logical connection independent of the underlying network, and the actual connection setting is performed by the service manager calling a management function that provides the connection using the subnet service.

The concept of the owner of a call (party) is necessary to clarify the authority to establish and release a call. Also, when adding or deleting a participant, this can affect multiple connections, so there must be a relationship between the participant and the connection, and there may be a relationship between the connections. For example, a voice connection and a video connection may be constrained to be kept in sync, thus maintaining the relationship between these connections. 4 illustrates a call related object constituting one service.

2.1 Specification of the connection

connection: = {connection_identifier, connection_mode, traffic_

characterist ics, QoS};

connecton_identifier: = {identifier};

connection_mode: = {p_to_p│p-to-mp│mp-to-p│broadcast};

p-to-p_attributes: = {source, destination};

p-to-mp_attributes: = {source, destinations};

mp-to-p_attributes: = {sources, destination};

broadcast_attributes: = {members};

source (s): = {identifier} ( ^* );

destination (s): = {identifier} ( ^* );

members: = {identifice} ^* ;

traffic_characteristice: = {characteristic_name, characteristic_value} ^* ;

QoS_characteristics: = {QoS_name, QoS_value} ^* ;

2.1 connecion mode

The properties of a connection belonging to a call have a form of connection first. In the past, common users could communicate by sending the same amount of data. However, various applications of the B-ISDN environment require asymmetric bidirectional communication and unidirectional communication in addition to general symmetric bidirectional communication. In the case of unidirectional communication, the data is continuously transmitted from the server and received from the client as in the current broadcasting service or file distribution service, except for the initial call setup process and the call release process. Is the case that does not exist. 5 shows an example of a communication configuration.

FIG. 5A shows a point-to-point unidirectional connection. The attribute that this unicast connection should have is information about the origin and destination of the data. Based on this unicast connection, (b) one-to-one bidirectional configuration, (c) one-to-multipoint unidirectional configuration, and (d) one-to-many bidirectional configuration. Here, (b) is the sum of two (a) directions opposite to each other, and (c) is the sum of three (a) directions with the same direction and different destinations. And (d) is the sum of three (b). (e) is a unidirectional one-to-many, ie multicast connection.

The difference between (c) and (e) is that (c) transmits data separately for each destination, whereas (e) simultaneously transmits the same data to multiple stages. By using this, it is possible to simultaneously transmit and receive at the same time (f) and send and receive all at the same time (g). Where (f) is the sum of one (e) and three (a), and (g) is the sum of three (e).

(h) is multipoint-to-point communication that receives data from multiple sources indistinguishably. You can combine this with the aforementioned forms to form a connection form (i) or (j).

(k) is a broadcast channel that sends and receives the same data to the whole. The fundamental difference between (g) and (k) is that in (g) you know exactly where you are sending the data, while in (k) you may not know all the members that actually receive the data. (A), (e), (h), and (k) in the figure above are basic connection types, and in other cases, a combination of basic connection behaviors.

2.1.2 data characteristics

The user must designate the traffic characteristics of the data to be requested to the communication service and the quality of service (QoS) to be provided by the communication service. This may include the average bandwidth, the highest bandwidth, the lowest bandwidth of the generated traffic, the maximum delay difference that must be provided in the network, and the rate of allowable service.

2.2 Relationship Object

Call objects, party objects, and connection objects mentioned in the call object model can express various relationships with each other in the call object model, and they must be reflected when providing services. In the OSI network management concept, when a parent node is requested to be deleted from a containment tree, the parent node can be deleted after deleting all the child nodes of the node. Therefore, when a call object is deleted, all party objects and connection objects derived from this object can be deleted together. Also, if one party object is deleted, the connection objects that the party is participating in will also be affected. This relationship is common to all cases, so it can be included when creating objects.

In contrast, however, there are cases where changes in child nodes affect the parent nodes in the include tree. There may be cases where the deletion of a particular party leads to the release of the call or the release of a particular connection leads to the release of the call, and there may also be various relationships between the connection and the party. To represent these various relationships, a relationship object is placed, which consists of a role and a set of references to the objects that play the role.

relationship: = {relationship_name, [role, object_reference] ^* } ^* ;

2.2.1 Relationship between calls and parties

In the past one-on-one communication, two parties participated in a single issue, and the withdrawal of one led to the release of the call. However, with the possibility of three-way or multi-party communication, the relationship between calls and parties can be more diverse. Some parties may play a major role in the withdrawal of the party that should lead to the release of the call, and there may be some parties withdrawing the party that will only affect the associated connection and not affect the state of the call. There must also be a party to be charged for the underlying resources. These various relationships can be between a call and a party.

call-tarty_relationship: = {is_owned_by (party_identifier),

[is_subordinate_to (party_iderntifier)] ^* };

2.2.2 Relationship between call and connection

In the past, there was a connection to an arc. Thus the release of the call was identified. In other words, the release of the call meant the release of the connection, and the release of the call was released. However, in a multimedia application there may be multiple connections in one call. Thus, the state of a connection and the state of a call can have several relationships. In general, connections belonging to a call are dependent on the call, so once a call is released, the connections belonging to it are also released. However, the release of a connection may not lead to the release of a call. For example, when the image connection is released during communication using voice and image, the voice connection may be maintained as it is and communication may continue. Alternatively, the call itself may be released by releasing the voice connection even when the video connection can be maintained. As such, there can be various relationships between arcs and connections, so these relationships must be maintained in the arc.

call-connection_relationship: = {[is_subordinate_to (connection_identifier) ^* };

2.2.3 Relationship between parties and connections

There may be multiple connections for communicating with one party. The aforementioned multimedia communication is an example. In this case, if a party withdraws from communication, all connections related to it must also be released. Conversely, if a particular connection the party is using is released, the party is also deleted and all related connections may be released.

party-connection_relationship: =

{[is_subordinate_to (party_identifier, connection_identifier)] ^* };

2.2.4 Relationship between Connections

There can be several relationships between connections in a call. First, in the case of one-to-one two-way communication, it consists of the sum of two one-to-one one-way connections, where a protocol of its own may exist. As such, the relationship between a connection and its corresponding connections should also be specified in the call.

In addition, even in the same direction, there may be a dependency relationship. In the case of an application that simultaneously delivers voice and video, if the voice connection is released, the connection to the image may be released together, or even if the image connection is lost, the condition for maintaining the connection may be different. In addition, in the case of a voice and video connection, there may be a synchronization relationship with each other, and a difference in transmission delay between connections may also be applied as a constraint.

inter-connection_relationship: = {[sync (connection_identiffier, connection_identifier)] ^* , [is_subordinate_to (connection_identifier, connection_identifier)] ^* , ..};

3. Service control using call object

3.1 User negotiation during call setup

The CSMF is responsible for informing the user of the current state of the network and for communicating the user's request to the network. When mobility is provided, the CSMF may be primarily responsible for tasks that are not directly related to the call, such as location management or authentication of individual users, but must be performed. Above all, the CSMF provides user-negotiated negotiations that are necessary in a future environment that provides various multi-media multimedia services. In the present invention, the user and the client are separated to give control over the call, and the client side allows only the expression of participation or non-participation in the call controlled by the user, but the extension is extended so that each user has the same authority and function. It is possible.

3.2 Service Control for Active Calls

There are two main cases in which the properties of a call object need to be changed while the call is active. The change in the call by the user's selection and the change of network state cause a decrease in the available bandwidth or QoS degradation. As a result, a situation occurs that does not meet the user's requirements.

Users using multimedia application services should be able to add new media or delete media they no longer need. When a new media is requested, this fact is transmitted to the SM through CSMF in the same way as the call setup process, and the SM provides this through negotiation process between users and resource allocation using RMF. In case of disconnecting existing connection, it checks related objects and performs necessary work to release resources.

Detection of network state changes is a function of the RMF of the SM. In fact, the management of the function and state of each network element is the work of the TMN's network management layer (NML) and element management layer (EML), and when a failure or resource shortage is detected in an element in the network, it responds to the user's requirements. It must be able to keep satisfying. If these management tasks cannot be supported, the RMF will be notified and the SM will inform each CSMF. In this case, the user can negotiate new communication conditions to maintain or release the call supporting dropped resources and QoS.

3.3 call release

When a call is released, the owner of the call deletes the call object, maintains the call, if a user who is absolutely necessary to leave, or the call-dependent connection is released.

Authority to create, delete, and change a call may be granted to each user differently, which is represented by the view that each user's CSMF shows to the user.

On the other hand, the call processing structure described above is a structure that can support a variety of multimedia multi-party communication in the integrated network environment. In the present invention, such a general processing structure will be limited to a form suitable for a computer network environment, and a service manager that will contain logic of various application services and provide a service will also limit functions to a connection manager type that provides a single service. In addition, all users can negotiate between users with the same rights and functions, but separate them into users and clients, and provide different functions and authorities, and provide limited management of network and system resources.

6 is a block diagram of a multicast communication apparatus using CORBA according to the present invention, which includes a user object 600, a connection manager 610, a source manager 620, a destination manager 630, and a source. The device handler 640, the destination device handler 650, the source device 660, and the destination device 670 are configured. The multicast communication apparatus using CORBA according to the present invention has a structure for transmitting a multimedia stream as well as supporting a unisession and unicast, and is composed of two parts for transmitting a signal and data for controlling the transmission. Control and management uses Common Object Request Broker Architecture (CORBA) communication, and the actual transmission of stream data uses Windows Sockets in a Windows NT environment. The communication of the user object 600, the connection manager 610, the source manager 620, and the destination manager 630 uses a socket between the device handlers 640 and 650 using CORBA.

The user object 600 has ownership over the multicast connection, requires connection control including at least multicast connection establishment and release, and requests data stream transmission control. The meaning of the user object here is to register the first user's name for multicast communication, to set up and release multicast, and to manage and control stream transmission. The user who actually wants to receive the stream transmission is not mentioned.

The user object 600 first establishes a connection with a group in order to perform stream transmission. When setting up a connection, information on the source and destination is provided to the connection manager 610, and after the connection is set up, the stream can be started, new members can be joined and left, and the stream can be transmitted. You can control stop, resume, pause, and so on.

The connection manager 610 supports multisession and multicast, manages a multicast connection according to a request from the user object 600, and controls a source manager 620 and a destination manager 630. The connection manager 610 is a CORBA object as the most important part for managing and controlling multimedia stream transmission. The connection manager 610 has a connection table for storing the state of the user object, group ID, source and destination. The connection manager 610 has a structure for supporting multisession and multicast. The connection manager 610 manages a user's name, group ID, group status, and source destinations in the connection table. When the user object 600 registers with the connection manager 610, the connection manager 610 checks whether the user object 600 is authorized and has authority and registers in the table. Send an error message. The group ID is allocated and recorded by the connection manager 610. In addition, the source and destination information records the data from the user object 600 in a table. To manage a session, it has a user name, group ID, group status, source, and destinations. For more than one session, this structure is managed as a linked list structure.

The source manager 620 is an CORBA object and manages the source device handler 640 under the control of the connection manager 610. The source manager 620 is an object that transmits stream data to various destinations. The source manager 620 needs to be able to connect with various devices in order to transmit various multimedia data, and stream transmission with various destinations performs a multicast function while transmitting in unicast with each destination.

The destination manager 630 is an CORBA object and manages the destination device handler 650 under the control of the connection manager 610. The destination manager 630 receives the source address and port number of the connection manager 610 and transmits the device handler 650 to the server side device handler and the socket connection. Also, as with the source, you need to connect with various devices.

The source device handler 640 controls the source device 660 by the management of the source manager 620 to support the stream transmission of data between the source device 660 and the destination device 670. The source device handler 640 connects to a real device and performs a socket connection between the source device handler 640 and the device handler 650 of the destinations to perform data transmission. For example, in a Windows NT environment, stream data can be transferred using a Windows socket.

The destination device handler 650 controls the destination device 670 by the management of the destination manager 630 to support the stream transmission of data between the source device and the destination device. Like the source device handler 640, it connects to an actual device and plays a role of data transmission by making a socket connection between the source device handler 640 and the device handler 650 of the destinations.

The devices 660 and 670 are physical devices that generate stream data. According to the type of multimedia data, if the data (fruit), the file is opened and the data is transmitted. If the image (BMP) file, the destination device 670 is displayed. Voice, video Devices for sending stream data, such as voice and video, include microphones, video cameras, speakers, and displays.

7 illustrates a process in which a user joins a group and establishes a connection in order to receive a multimedia service. 7 to 12, Ug denotes a user object 600, C denotes a connection manager 610, S denotes a source manager 620, d1 and d2 denote a destination manager 630, and H denotes a source. Source device handler 640 if connected with a manager, destination device handler 650 if connected with a destination manager, d represents source device 660 if connected with a source device handler, destination if connected with a destination device handler Represent the device 670. In the table, Conn_id is the connection ID, gid is the group ID, S is the source, d1, d2, d3 is the destination, r is ready, o is open, and d is delete or leave. . And reference numerals in the drawings indicate respective flows.

1. The user object (Ug) requests the connection manager (C) to set up a multicast using the username, source address, and destination address as parameters.

2. After receiving the multicast request, the connection manager (C) checks the authority of the user object (Ug), and if there is authority, registers the connection table, grants gid, and requests the device and the device to open the device. . Start the timer with a request. If the user does not have permission, the request is rejected.

3. The source manager S and the destination managers d1 and d2 who have received a request for device open from the connection manager C request the device handler H to prepare the device.

4. The device handler H requests the actual multimedia device to prepare the device.

5. The result of the device preparation is given to the device handler (H).

6. The device handler (H) gives the source manager (S) and the destination manager (d1, d2) the result of device preparation.

7. The source manager (S) and the destination manager (d1, d2) gives the connection manager (C) the result of whether the device (d) is ready. Stop the timer and register the result of the prepared source and destination in the connection table until then.

8. The device d requests the prepared source manager S and the destination manager d to establish a substantial connection. While the connection manager (C) establishes a connection, the device (d) is not ready and waits for a message that the device (d) is ready at the destination where the connection cannot be established.

9. The source manager (S) and the destination manager (d1, d2) request the device handler (H) to establish a connection using a socket.

10. Use the socket to establish the connection between the device handlers (H).

11. The destination device handler (H, 650) returns the result of the connection establishment to the source device handler (H, 640).

12. The result of the destinations for which the connection is established is transmitted to the source manager (S).

13. The source manager (S) returns to the connection manager (C) the addresses and results of the destinations that have been established. Record this result in the linked table.

14. Connection manager (C) returns gid to user object (Ug).

8 is a diagram illustrating a process of starting a stream transmission using a group ID (gid) received from the connection manager C after joining a group and establishing a connection.

1. After receiving the gid from the connection manager (C), the user object (Ug) gives a command called start to start the multimedia stream transmission. At this time, the gid is requested to the connection manager (C) as a parameter.

2. The connection manager (C) gives the source and the destination a command to start the stream transmission.

3. The source manager S and the destination managers d1 and d2 give the device handler H a start command. The device handler H of the source 620 substantially transmits data to the device handler H of the destinations.

4. Give the source manager (S) the result of the start command.

5. Give the result to the connection manager (C).

6. Give the user object (Ug) that the stream transmission has started.

Start, stop, stop, and pause the transmission of the stream operate in the same way as the start of the stream transmission.

9 illustrates a process in which a user object Ug joins a group in which a current session is opened.

1. The user object (Ua) obtains the gid (Group Identifier) of the group in which the current session is opened from the connection manager (C) and connects to the session. When connecting to a session, connect to the gid with the new destination address as a parameter and join the group.

Since the current session is open, a new member is registered and connected to the connection table. The rest of the operations are the same as when the first multicast group is connected.

10 illustrates a process in which a newly subscribed member starts a stream transmission in order to receive a service.

1. After receiving gid from connection manager (C), user object (Ua) commands start to start multimedia stream transmission. At this time, gid is given as a parameter. Other operations are the same as in FIG.

11 is a view illustrating an operation in which a member who does not use a service among members subscribed to the group leaves the group, and this will be described below.

1. Request connection manager (C) with gid of session and device address to leave.

2. Upon receiving the request, the connection manager (C) deletes the destination address to be removed from the connection table and gives a command to the source manager (S) and the destination manager (d3) to leave.

3. The source manager (S) deletes the contents of the destination from the source table and gives the result to the connection manager (C).

4. The connection manager (C) gives the result to the user object (Ud).

5. 6,7,8 is the process of closing the open device and closing the socket of the device handler.

12 is for explaining disconnection, which will be described below.

1. The user object (Ug) requests the connection manager (C) with a group ID as a parameter to disconnect.

2. Upon receiving the request, the connection manager (C) deletes the contents of the session to be released from the connection table and gives the release command to the source manager (S) and the destination manager (d1).

3. The source manager (S) deletes the contents of the source and the destination from the source table and gives the result to the connection manager (C).

4. The connection manager (C) gives the result to the user object (Ug).

5, 6, 7, and 8 are processes of closing an open device and closing a socket connection of the device handler (H).

CORBA communication, on the other hand, is achieved by a client calling a server method by referencing an object reference of a server object. The object reference contains the host, the object's executable, and so on. The advantage of using CORBA is that it provides transparency, allowing the application to be developed independently of the language and OS. Developers can develop only if they know the interface defined by IDL. Components can play the role of server and client at the same time and prevent blocking by using Oneway method to support multi-session. Thus, other requests can be accepted while the request is in progress.

Meanwhile, in order to efficiently manage session data, the connection manager must store information related to the session for each session, and manage the session information in the form of a connection list in order to support multisession.

According to the present invention, it is a control and management method for multi-session, multicast, and multimedia stream transmission by introducing the concept of a distributed environment, and the transparency provided by a distributed platform, for example, access transparency, location transparency, and concurrency transparency. , Redundant transparency, and the like.

In addition, various services, for example, naming (Naming), trading services, life cycle (Life cycle) services can be used for smooth communication between objects, and objects (servers) that provide a variety of services can be used.

Currently, most algorithms only support point-to-point communication (unicast), but the present invention provides multi-session, multicast, and multimedia stream transmission, and can control and manage this transmission.

In addition, as it adopts the connection management structure that is independent of the underlying network technology, it is expected that the ATM information can be transmitted in the future without using TCP / IP.

Claims (8)

A user object having ownership over a multicast connection, requesting connection control including at least multicast connection establishment and teardown, and requesting data stream transmission control; As an object of CORBA, a connection manager that supports multisession and multicast, manages a multicast connection according to a request from the user object, and controls a source manager and a destination manager; An object of CORBA, the source manager managing a source device handler under the control of the connection manager; An object of CORBA, the destination manager managing a destination device handler under the control of the connection manager; A source device handler which controls a source device by management of the source manager to support a stream transmission of data between the source device and the destination device; And And a destination device handler which controls a destination device by management of the destination manager and supports a stream transmission of data between the source device and the destination device. The method of claim 1, wherein the connection manager And a connection table for storing state of the user object, group ID, source and destination. The method of claim 2, wherein the group join and connection setting of the user object for receiving a multimedia service is 1) the user object asks the connection manager to set up multicast using the username, source address and destination address as parameters; 2) The connection manager checks the user's authority for the multicast request, and if there is authority, registers in the connection table, gives the group ID (gid), and requests device_open from the source and destination managers to prepare the device. Start a timer, deny the request if the user is not authorized, 3) The source manager and the destination manager who have received the request for device open from the connection manager request the device handler to prepare the device. 4) The device handler prepares the device by requesting preparation from the actual multimedia device, 5) Inform the device handler of the result of device preparation, 6) The device handler informs the source manager and the destination manager whether the device is ready or not, 7) The source manager and the destination manager give the connection manager the result of device preparation, stop the timer, and register the result of the source and destination device prepared until then in the connection table. 8) When the device requests the actual source and destination managers to establish the actual connection and the destination manager fails to establish the connection because the device is not ready while the connection manager establishes the connection, the device is ready to wait for the message that the device is ready. Start the connection setup right away, 9) The source and destination managers request device handlers to establish a connection using sockets. 10) Set up a connection using a socket between device handlers, 11) The destination device handler returns the result of the connection establishment to the source device handler. 12) delivers the results of the established destinations to the source, 13) The source returns to the connection manager the address and result of the established destinations, and records the result in the connection table. 14) A multicast communication device using CORBA, wherein the connection manager is configured to return a group ID (gid) to a user. The method of claim 2, wherein after the group joining and connection establishment of the user object for receiving the multimedia service is made, the start of stream transmission using the group ID received from the connection manager is performed. 1) After receiving the gid from the connection manager, the user object gives a command called start to start transmission of the multimedia stream. At this time, the connection manager requests the connection manager with the gid as a parameter. 2) The connection manager gives the source and destination managers a start command for stream transmission. 3) The source manager and the destination manager give a start command to the device handler, and the device handler of the source substantially transmits data to the device handlers of the destinations. 4) Give the source manager the result of the start command, 5) Give the result to the connection manager, 6) A multicast communication device using CORBA, characterized by giving a result that a stream transmission has been started to a user. 3. The method of claim 2, wherein the user object joins a group with a session open. 1) The user obtains the gid of the group in which the current session is open from the connection manager, and connects to the session. 2) When connecting to the session, connect the gid to the new destination address with parameters and join the group. 3) A multicast communication device using CORBA, which includes registering a new member in the connection table and making a connection because the current session is open. The method of claim 2, wherein the withdrawal of the group of members who do not use the service among the members subscribed to the group 1) Ask the connection manager for the gid of the session and the device address to leave. 2) Upon receiving the request, the connection manager deletes the destination address to withdraw from the connection table and gives a command to the source and destination to leave. 3) The source manager deletes the contents of the destination from the source table and gives the result to the connection manager. 4) The connection manager gives the result to the user object, 5) A multicast communication device using CORBA, comprising closing an open device and closing the socket connection of the device handler. The method of claim 2, wherein the disconnection is 1) In order for the user object to disconnect, ask the connection manager as a parameter the group ID. 2) Upon receiving the request, the connection manager deletes the contents of the session to be released from the connection table and gives the release command to the source and destination managers. 3) The source manager deletes the contents of the source and the destination from the source table, and gives the result to the connection manager. 4) The connection manager gives the result to the user object, 5) A multicast communication device using CORBA, comprising closing an open device and closing a socket connection of a device handler. For multisession and multicast, comprising a user, a connection manager, a source manager and a destination manager as distributed objects, and connecting signals through CORBA communication using the distributed objects; And And when a signal is connected between the source and the destination through the signal connection, transmitting data using a socket through a device handler. The user is an object used for the administrator to set up to perform the necessary work in the entire connection process, the connection manager manages the multicast connection by the request from the user and controls the source manager and the destination manager, The source manager and the destination manager are objects that abstract the source and destination of the multicast connection, and manage each device handler under the control of the connection manager. The device handler is connected to the source and the destination, and controls the multimedia device to support connection establishment and transmit data, CORBA.