Version imprimable
Bonjour,
Je voudrais savoir s'il existe un équivalent en C# pour ces libs en Java :
import java.nio.channels.SelectableChannel;
import java.nio.channels.SelectionKey;
import java.nio.channels.Selector;
import java.nio.channels.SocketChannel;
import java.nio.channels.spi.SelectorProvider;
@ +
Ca aiderait si tu nous disais à quoi elles servent... a priori la plupart des gens ici ne sont pas experts en Java
Voici la doc sur l'API Java, bien sur moi je ne comprend même pas le procédé, mais il me semble que ca parle de canaux et de flux réseaux en mode non-bloquant. Si quelqu'un pouvais m'éclaircir la dessus , ca m'aiderais grandement. Merci
Doc API :
java.nio.channels.socketchannels
java.nio.channels.selectorCitation:
A selectable channel for stream-oriented connecting sockets.
Socket channels are not a complete abstraction of connecting network sockets. Binding, shutdown, and the manipulation of socket options must be done through an associated Socket object obtained by invoking the socket method. It is not possible to create a channel for an arbitrary, pre-existing socket, nor is it possible to specify the SocketImpl object to be used by a socket associated with a socket channel.
A socket channel is created by invoking one of the open methods of this class. A newly-created socket channel is open but not yet connected. An attempt to invoke an I/O operation upon an unconnected channel will cause a NotYetConnectedException to be thrown. A socket channel can be connected by invoking its connect method; once connected, a socket channel remains connected until it is closed. Whether or not a socket channel is connected may be determined by invoking its isConnected method.
Socket channels support non-blocking connection: A socket channel may be created and the process of establishing the link to the remote socket may be initiated via the connect method for later completion by the finishConnect method. Whether or not a connection operation is in progress may be determined by invoking the isConnectionPending method.
The input and output sides of a socket channel may independently be shut down without actually closing the channel. Shutting down the input side of a channel by invoking the shutdownInput method of an associated socket object will cause further reads on the channel to return -1, the end-of-stream indication. Shutting down the output side of the channel by invoking the shutdownOutput method of an associated socket object will cause further writes on the channel to throw a ClosedChannelException.
Socket channels support asynchronous shutdown, which is similar to the asynchronous close operation specified in the Channel class. If the input side of a socket is shut down by one thread while another thread is blocked in a read operation on the socket's channel, then the read operation in the blocked thread will complete without reading any bytes and will return -1. If the output side of a socket is shut down by one thread while another thread is blocked in a write operation on the socket's channel, then the blocked thread will receive an AsynchronousCloseException.
Socket channels are safe for use by multiple concurrent threads. They support concurrent reading and writing, though at most one thread may be reading and at most one thread may be writing at any given time. The connect and finishConnect methods are mutually synchronized against each other, and an attempt to initiate a read or write operation while an invocation of one of these methods is in progress will block until that invocation is complete.
java.nio.channels.selectionkeyCitation:
A multiplexor of SelectableChannel objects.
A selector may be created by invoking the open method of this class, which will use the system's default selector provider to create a new selector. A selector may also be created by invoking the openSelector method of a custom selector provider. A selector remains open until it is closed via its close method.
A selectable channel's registration with a selector is represented by a SelectionKey object. A selector maintains three sets of selection keys:
*
The key set contains the keys representing the current channel registrations of this selector. This set is returned by the keys method.
*
The selected-key set is the set of keys such that each key's channel was detected to be ready for at least one of the operations identified in the key's interest set during a prior selection operation. This set is returned by the selectedKeys method. The selected-key set is always a subset of the key set.
*
The cancelled-key set is the set of keys that have been cancelled but whose channels have not yet been deregistered. This set is not directly accessible. The cancelled-key set is always a subset of the key set.
All three sets are empty in a newly-created selector.
A key is added to a selector's key set as a side effect of registering a channel via the channel's register method. Cancelled keys are removed from the key set during selection operations. The key set itself is not directly modifiable.
A key is added to its selector's cancelled-key set when it is cancelled, whether by closing its channel or by invoking its cancel method. Cancelling a key will cause its channel to be deregistered during the next selection operation, at which time the key will removed from all of the selector's key sets.
Keys are added to the selected-key set by selection operations. A key may be removed directly from the selected-key set by invoking the set's remove method or by invoking the remove method of an iterator obtained from the set. Keys are never removed from the selected-key set in any other way; they are not, in particular, removed as a side effect of selection operations. Keys may not be added directly to the selected-key set.
Selection
During each selection operation, keys may be added to and removed from a selector's selected-key set and may be removed from its key and cancelled-key sets. Selection is performed by the select(), select(long), and selectNow() methods, and involves three steps:
1.
Each key in the cancelled-key set is removed from each key set of which it is a member, and its channel is deregistered. This step leaves the cancelled-key set empty.
2.
The underlying operating system is queried for an update as to the readiness of each remaining channel to perform any of the operations identified by its key's interest set as of the moment that the selection operation began. For a channel that is ready for at least one such operation, one of the following two actions is performed:
1.
If the channel's key is not already in the selected-key set then it is added to that set and its ready-operation set is modified to identify exactly those operations for which the channel is now reported to be ready. Any readiness information previously recorded in the ready set is discarded.
2.
Otherwise the channel's key is already in the selected-key set, so its ready-operation set is modified to identify any new operations for which the channel is reported to be ready. Any readiness information previously recorded in the ready set is preserved; in other words, the ready set returned by the underlying system is bitwise-disjoined into the key's current ready set.
3. If all of the keys in the key set at the start of this step have empty interest sets then neither the selected-key set nor any of the keys' ready-operation sets will be updated.
If any keys were added to the cancelled-key set while step (2) was in progress then they are processed as in step (1).
Whether or not a selection operation blocks to wait for one or more channels to become ready, and if so for how long, is the only essential difference between the three selection methods.
Concurrency
Selectors are themselves safe for use by multiple concurrent threads; their key sets, however, are not.
The selection operations synchronize on the selector itself, on the key set, and on the selected-key set, in that order. They also synchronize on the cancelled-key set during steps (1) and (3) above.
Changes made to the interest sets of a selector's keys while a selection operation is in progress have no effect upon that operation; they will be seen by the next selection operation.
Keys may be cancelled and channels may be closed at any time. Hence the presence of a key in one or more of a selector's key sets does not imply that the key is valid or that its channel is open. Application code should be careful to synchronize and check these conditions as necessary if there is any possibility that another thread will cancel a key or close a channel.
A thread blocked in one of the select() or select(long) methods may be interrupted by some other thread in one of three ways:
*
By invoking the selector's wakeup method,
*
By invoking the selector's close method, or
*
By invoking the blocked thread's interrupt method, in which case its interrupt status will be set and the selector's wakeup method will be invoked.
The close method synchronizes on the selector and all three key sets in the same order as in a selection operation.
A selector's key and selected-key sets are not, in general, safe for use by multiple concurrent threads. If such a thread might modify one of these sets directly then access should be controlled by synchronizing on the set itself. The iterators returned by these sets' iterator methods are fail-fast: If the set is modified after the iterator is created, in any way except by invoking the iterator's own remove method, then a ConcurrentModificationException will be thrown.
java.nio.channel.selectablechannelCitation:
A token representing the registration of a SelectableChannel with a Selector.
A selection key is created each time a channel is registered with a selector. A key remains valid until it is cancelled by invoking its cancel method, by closing its channel, or by closing its selector. Cancelling a key does not immediately remove it from its selector; it is instead added to the selector's cancelled-key set for removal during the next selection operation. The validity of a key may be tested by invoking its isValid method.
A selection key contains two operation sets represented as integer values. Each bit of an operation set denotes a category of selectable operations that are supported by the key's channel.
*
The interest set determines which operation categories will be tested for readiness the next time one of the selector's selection methods is invoked. The interest set is initialized with the value given when the key is created; it may later be changed via the interestOps(int) method.
*
The ready set identifies the operation categories for which the key's channel has been detected to be ready by the key's selector. The ready set is initialized to zero when the key is created; it may later be updated by the selector during a selection operation, but it cannot be updated directly.
That a selection key's ready set indicates that its channel is ready for some operation category is a hint, but not a guarantee, that an operation in such a category may be performed by a thread without causing the thread to block. A ready set is most likely to be accurate immediately after the completion of a selection operation. It is likely to be made inaccurate by external events and by I/O operations that are invoked upon the corresponding channel.
This class defines all known operation-set bits, but precisely which bits are supported by a given channel depends upon the type of the channel. Each subclass of SelectableChannel defines an validOps() method which returns a set identifying just those operations that are supported by the channel. An attempt to set or test an operation-set bit that is not supported by a key's channel will result in an appropriate run-time exception.
It is often necessary to associate some application-specific data with a selection key, for example an object that represents the state of a higher-level protocol and handles readiness notifications in order to implement that protocol. Selection keys therefore support the attachment of a single arbitrary object to a key. An object can be attached via the attach method and then later retrieved via the attachment method.
Selection keys are safe for use by multiple concurrent threads. The operations of reading and writing the interest set will, in general, be synchronized with certain operations of the selector. Exactly how this synchronization is performed is implementation-dependent: In a naive implementation, reading or writing the interest set may block indefinitely if a selection operation is already in progress; in a high-performance implementation, reading or writing the interest set may block briefly, if at all. In any case, a selection operation will always use the interest-set value that was current at the moment that the operation began.
Citation:
A channel that can be multiplexed via a Selector.
In order to be used with a selector, an instance of this class must first be registered via the register method. This method returns a new SelectionKey object that represents the channel's registration with the selector.
Once registered with a selector, a channel remains registered until it is deregistered. This involves deallocating whatever resources were allocated to the channel by the selector.
A channel cannot be deregistered directly; instead, the key representing its registration must be cancelled. Cancelling a key requests that the channel be deregistered during the selector's next selection operation. A key may be cancelled explicitly by invoking its cancel method. All of a channel's keys are cancelled implicitly when the channel is closed, whether by invoking its close method or by interrupting a thread blocked in an I/O operation upon the channel.
If the selector itself is closed then the channel will be deregistered, and the key representing its registration will be invalidated, without further delay.
A channel may be registered at most once with any particular selector.
Whether or not a channel is registered with one or more selectors may be determined by invoking the isRegistered method.
Selectable channels are safe for use by multiple concurrent threads.
Blocking mode
A selectable channel is either in blocking mode or in non-blocking mode. In blocking mode, every I/O operation invoked upon the channel will block until it completes. In non-blocking mode an I/O operation will never block and may transfer fewer bytes than were requested or possibly no bytes at all. The blocking mode of a selectable channel may be determined by invoking its isBlocking method.
Newly-created selectable channels are always in blocking mode. Non-blocking mode is most useful in conjunction with selector-based multiplexing. A channel must be placed into non-blocking mode before being registered with a selector, and may not be returned to blocking mode until it has been deregistered.
A première vue comme ça, je dirais certaines classes de System.IO et System.Net. Après la philosophie de .NET et Java n'est pas forcément la même (surtout sur ce point là on dirait) et donc je ne penses pas qu'il existe de vraies équivalences. Il est juste possible de faire la même chose...
Tu as une idée de la manière de reproduire un peu le même procédé en C# ?
Est-ce que tu as une idee de ce que tu veux faire ???Citation:
Envoyé par mizuka
Parce que personnelement, j'ai la flemme de me taper une demi page de javadoc ;)
Alors j'explique ce que j'aimerais faire,
Je suis entrain de coder un programme ayant une relation client/serveur.
J'aimerais coder un Dispatcher pour distribuer des packets provenant du client pour que le serveur puisse transmettre les packets au bon endroit pour les décoder, les traiter pour ensuite envoyer la réponse au client. Mais actuellement mes compétences en réseau sont assez faible c'est pour cela que je n'y comprend absolument rien.
J'aurais voulu aussi savoir comment utiliser les canaux en C# de la même manière qu'ils sont utilisés en JAVA. J'espère avoir été assez clair dans mes explications, dans le doute je préciserais.
Merci.
Y'a t'il une équivalence en C# ?Citation:
Channels :
Connections to files, sockets etc that support
non-blocking reads
Buffers :
Array-like objects that can be directly read or
written by Channels
Selectors :
Tell which of a set of Channels have IO events
SelectionKeys :
Maintain IO event status and bindings
Juste une petite question ... est-ce qu'une partie du code est / sera en Java ?
Si ce n'est pas le cas, je ne vois pas l'intérêt de vouloir faire "comme en Java" dans un langage qui n'est pas Java. En .NET, on utilise les Stream (System.IO) qui permet la lecture d'un FileStream (fichier) ou NetworkStream (réseau) ou autre de façon synchrone (bloquant) ou asynchrone (non-bloquant). La lecture d'un Stream retourne un tableau de bytes (buffer). Il est également possible d'utiliser la classe Socket (System.Net) pour envoyer et/ou recevoir des informations via le réseau. Les Sockets possèdent des méthodes de lecture/écriture synchrones et asynchrones. En fonction des données lues par le Socket, il suffit ensuite d'écrire les traitements adéquats pour retourner les bonnes informations au client.
Si une partie du code est en Java, on entre dans une problèmatique d'intéropérabilité. Ces librairies étant spécifiques à Java, je ne penses pas du tout qu'elles soient intéropérables avec .NET. En général, on passe plus par des WebServices pour faire communiquer les mondes Java et .NET.
Quoi qu'il en soit, .NET ne propose pas le genre d'abstraction que semble propose cet espace de nom. Soit on code tout à la main (Stream / Socket), soit on utilise une abstraction de protocole (TcpClient par exemple), soit une abstraction complète des échanges (WebServices, WCF).
Coucou Kaidan, merci de tes conseils. Alors pour info, je passe justement d'un code déja existant en JAVA vers la plateforme .NET car non seulement je préfère le C# et en plus je connais mieux le langage que Java. Or ca va être ma première expérience dans le réseau et tout ce que Java implante dans leur API me porte énormément à confusion par rapport a .NET ou apparemment la gestion des flux n'ont rien à voir.Si tu peux m'en dire plus sur ça je suis tout ouï ! :)
Pour ce qui est de l'interopérabilité Java/.Net tu peux utiliser IKVM.
Il sera alors inutile de réécrire ton code en C#, et tu pourras même utiliser depuis C# les apis Java comme celles que tu cites.
Merci pour ta réponse seriousme ! C'est une vraie mine d'or que tu m'a conseillé la , même si j'aurais préféré entièrement coder cela avec les libs .NET Framework , IKVM me convient. Encore merci.