Client écoute port TCP

Version imprimable

06/01/2014, 21h56
jadey

Client écoute port TCP
Hello les gens,
Je suis quelqu’un que l'on peut qualifier de totalement néophyte en matière de programmation réseau ayant jusqu'ici fait plutôt du développement web java.

L’objet de mon post réside dans le fait que l'on me demande d'assister a une réunion ou il s'agira de discuter de la mise en place d'un échange de données (consistant en des contrats pour les plus curieux d'entre vous) au travers de l’écoute sur un port en TCP mis a disposition par l'un de nos partenaires (une "institution" distincte autrement dit... qui a dit securite ???) d’après ce que j'ai cru comprendre jusqu’ici.
Il me sera surement demande dans un premier temps de chiffrer la charge totale estimative de la mise en place d'un tel client qui sera code en java, et j’aurai donc besoin de savoir un peu ce a quoi je devrais faire attention et les bonnes questions a se poser et a poser lors de la réunion:
1- Qu'est ce qui se fait de bien en la matière aujourd'hui ? Est ce que je suis "bon" (comprenez uptodate) si je prévois du multithreading des sockets et l'utilisation des api java classiques (package java.net ?)
2-y a t'il possibilité sinon d'utiliser RMI ? des ejb ?
3-Si on part sur ces technos, a combien devrait se chiffrer la partie développement en j/h de dev sachant que d’après ce que j'ai comme info jusqu’ici est que le flux a écouter sera surement du genre:
Code:

1 2 3 début de transmission contrat1, contrat2, contratn fin de transmission
et que la partie serveur est déjà développée par l’entité ayant pour responsabilité l'emission des contrats.
4-D'autres choses que j'oubli surement et dont je devrais m'assurer lors de la réu.
Merci pour toutes vos contributions.
06/01/2014, 22h29
tchize_

Citation:

Envoyé par jadey

1- Qu'est ce qui se fait de bien en la matière aujourd'hui ? Est ce que je suis "bon" (comprenez uptodate) si je prévois du multithreading des sockets et l'utilisation des api java classiques (package java.net ?)

Je ne vois pas comment tu envisage en jaav d'attaquer du réseau sans que les packages java.net ne soient impliqués à un niveau ou un autre :mouarf:

Citation:

Envoyé par jadey

2-y a t'il possibilité sinon d'utiliser RMI ? des ejb ?

Vu que le service est déjà existant chez le tiers et que le but est de t'y connecter, tu devra faire avec ce qu'il te fournis. Pour faire simple, ejb et RMI, c'est un service fournis par un serveur en java pour un client en java. Donc si des services tiers sont impliqués, peu de chances d'utiliser ça.

Citation:

Envoyé par jadey

3-Si on part sur ces technos, a combien devrait se chiffrer la partie développement en j/h de dev

Combien de jours homme il me faut pour mettre en place l'envoi toutes les 5 minutes à mon client de la température à 6m à Namur? Trop vague comme question, on ne peux pas répondre. Ca dépend des contraites de sécurités, des protocoles de tests, de la validations, des spécificités des données, des tiers impliqués, des protocoles de livraison, du type de réseau, de la fréquence de traitement, de la redondance demandées, .....

Sache simplement qu'un EJB tout con, aujourd'hui, ca se code en trois coup de cuillère. 3/4 méthodes, 2 annotations, et c'est emballé. Mais c'est un EJB de base. Si t'as des trucs compliqués à traiter, t'aura des solution compliquées :)
07/01/2014, 17h46
jadey

Citation:

Pour faire simple, ejb et RMI, c'est un service fournis par un serveur en java pour un client en java. Donc si des services tiers sont impliqués, peu de chances d'utiliser ça.

Chui con :aie:

Citation:

Ça dépend des contraintes de sécurités

L'utilisation d'une ligne spécialisée est très probable seulement comment fait on pour sécuriser un tel flux au travers du code? SSL? JCE ?(Java Cryptography Extension) Encore une fois cela dépend du serveur et il faudra se conformer à ce qui est implémenté comme techno n'est ce pas ?

Citation:

des protocoles de livraison

Qesaco ?

Citation:

de la redondance demandées

Qesaco ?
07/01/2014, 19h28
tchize_

Pour la sécurité, tout dépend de ce qui est déjà prévu dans le serveur, difficile d'amener quelque choise de nouveau à cet endroit là si j'ai bien compris.

Pour le reste, tu va recevoir les données en continu? Tu va avoir des flux de données avec des pics à certaines périodes à assimiler? Tu dois confirmer toute les réceptions? La procédure est transactionnelle? Faut-il assurer une redondance en cas de chute de ton serveur, quel est l'éventuel SLA concerné....
08/01/2014, 14h27
JoeChip

Citation:

L'utilisation d'une ligne spécialisée est très probable seulement comment fait on pour sécuriser un tel flux

Sécuriser contre quoi ? Si c'est une ligne directe ("spécialisée"...?) quelles sont les attaques possibles ?
Normalement, c'est sécurisé à l'autre bout... Donc il faut demander au fournisseur du service quelles sécurités sont en place...
28/01/2014, 18h49
jadey

Citation:

Normalement, c'est sécurisé à l'autre bout

En effet c'est ce que j'ai compris à l'issu de la réu.
La partie serveur a été développée en VBA, du coup pas d'exigences particulière en matière de sécurité ni en matière de quoi que ce soit à vrai dire.
Par contre de notre côté on me demande "d'explorer" certaines pistes, notamment:
- Il faudrait peut être prévoir un écran pour monitorer le bousin.
- Le démon devra pouvoir tourner sur deux machines au cas ou l'une d'elle tomberai le deuxième devra prendre le relais.
- Certaines données devront être persistées en BD.

Je me demande si je ne devrais pas orienter le développement vers une appli. c'est peut être une déformation inhérente à ce que j'ai eu à faire jusqu'ici (développement web) mais je trouve la description de ce qu'il m'est demandé de réaliser plus proche d'une appli. web que d'un démon qu'en pensez vous ?

J'ai aussi une question technique après avoir réalisé un petit TP d'un client serveur communiquant en socket: Pas besoin de faire du multitrading vu que je ne développe que la partie client n'est ce pas ?
28/01/2014, 19h36
JoeChip

Appli web hébergée où ? En local, ou alors c'est moins sécu non ? Du coup au lieu d'avoir une appli locale qui gère le toutim sur deux postes séparés, t'as la même chose mais avec en plus une gestion de serveurs. Perso je ferais une appli JavaWS qui fait tout en local, avec les données chiffrées sur un DB "remote". Mais bon, faut reconnaître que c'est peut-être parce que je suis surtout habitué à faire comme ça :)
29/01/2014, 20h19
jadey

Citation:

je ferais une appli JavaWS qui fait tout en local

Oui, mais ce serait juste du travail en plus pour moi sans grande valeur ajoutée. Je pense notamment à ce qu'offre une appli. et aux services que fournit ou qui peuvent être configurés grâce à l'apport de l'utilisation d'un serveur d'appli. (écran, persistance, load balancing)

Citation:

- Il faudrait peut être prévoir un écran pour monitorer le bousin.

J'ai aussi pensé à leur vendre chainsaw dispo. avec Log4j comme étant du monitoring niark niark :mrgreen: ça peut passer?