LONGITUD DE ARCHIVO
8 views
Skip to first unread message
Juan Pablo Eguinlian
Dec 12, 2009, 6:28:01 PM12/12/09
to SEMINARIO DE REDES - TP FINAL
A raíz de la respuesta que envio Nicolás, creemos es necesaria la
inclusión de un campo que contenga el tamaño en bytes del archivo a
enviar.
Este campo se propone insertarlo en la aplicación del cliente al
momento de solicitar un PUT:
PUT “nombre_archivo” v”número_version” "Tamaño en bytes""\n"
“USER”"\n"
“PASS”"\n"
"\n"
“DATOS……….. EOF”"\n"
En tanto la aplicación del servidor al responder la solicitud de GET
por parte del cliente, responderá:
"STATUS xxx" “nombre_archivo” "Tamaño en bytes""\n"
"\n"
“DATOS……….. EOF”"\n"
En caso de bajarse el archivo de manera incompleta, tanto el server
como el cliente comparán el tamaño bajado con el total "esperado",
descartará el archivo y enviará un código de error. en caso de
producirse un corte en la conexión se detectará de igual manera y
también se descartará el archivo.
En cuanto a las longitudes en los campos máximas se propones limitar:
Nombre del archivo-----------15 caracteres
Usuario----------------------------10 caracteres
password-------------------------10 caractreres
Si el nombre de un archivo enviado por un cliente, coincide con el
nombre de uno de los archivos existentes en el servidor. Este enviará
un código de error para que el cliente renombre el archivo y cortará
la conexion. En caso contrario se sobrescribiria el archivo, perdiendo
el original.
Habría que especificar una longitud máxima de archivos a transferir de
modo de evitar que un usuario se adueñe de la conexión.
Saludos!
inclusión de un campo que contenga el tamaño en bytes del archivo a
enviar.
Este campo se propone insertarlo en la aplicación del cliente al
momento de solicitar un PUT:
PUT “nombre_archivo” v”número_version” "Tamaño en bytes""\n"
“USER”"\n"
“PASS”"\n"
"\n"
“DATOS……….. EOF”"\n"
En tanto la aplicación del servidor al responder la solicitud de GET
por parte del cliente, responderá:
"STATUS xxx" “nombre_archivo” "Tamaño en bytes""\n"
"\n"
“DATOS……….. EOF”"\n"
En caso de bajarse el archivo de manera incompleta, tanto el server
como el cliente comparán el tamaño bajado con el total "esperado",
descartará el archivo y enviará un código de error. en caso de
producirse un corte en la conexión se detectará de igual manera y
también se descartará el archivo.
En cuanto a las longitudes en los campos máximas se propones limitar:
Nombre del archivo-----------15 caracteres
Usuario----------------------------10 caracteres
password-------------------------10 caractreres
Si el nombre de un archivo enviado por un cliente, coincide con el
nombre de uno de los archivos existentes en el servidor. Este enviará
un código de error para que el cliente renombre el archivo y cortará
la conexion. En caso contrario se sobrescribiria el archivo, perdiendo
el original.
Habría que especificar una longitud máxima de archivos a transferir de
modo de evitar que un usuario se adueñe de la conexión.
Saludos!
Moretti Nicolas
Dec 12, 2009, 6:57:07 PM12/12/09
to seminario-de-re...@googlegroups.com
Por mi no hay problema..
solamente pongan numero a los STATUS y definicion asi se incorpora
saludos
Moretti
-----Mensaje original-----
De: seminario-de-re...@googlegroups.com
[mailto:seminario-de-re...@googlegroups.com]En nombre de
Juan Pablo Eguinlian
Enviado el: s�bado, 12 de diciembre de 2009 20:28
Para: SEMINARIO DE REDES - TP FINAL
Asunto: LONGITUD DE ARCHIVO
A ra�z de la respuesta que envio Nicol�s, creemos es necesaria la
inclusi�n de un campo que contenga el tama�o en bytes del archivo a
enviar.
Este campo se propone insertarlo en la aplicaci�n del cliente al
�USER�"\n"
�PASS�"\n"
"\n"
�DATOS���.. EOF�"\n"
En tanto la aplicaci�n del servidor al responder la solicitud de GET
por parte del cliente, responder�:
"STATUS xxx" �nombre_archivo� "Tama�o en bytes""\n"
"\n"
�DATOS���.. EOF�"\n"
En caso de bajarse el archivo de manera incompleta, tanto el server
como el cliente compar�n el tama�o bajado con el total "esperado",
descartar� el archivo y enviar� un c�digo de error. en caso de
producirse un corte en la conexi�n se detectar� de igual manera y
tambi�n se descartar� el archivo.
En cuanto a las longitudes en los campos m�ximas se propones limitar:
un c�digo de error para que el cliente renombre el archivo y cortar�
modo de evitar que un usuario se adue�e de la conexi�n.
Saludos!
solamente pongan numero a los STATUS y definicion asi se incorpora
saludos
Moretti
-----Mensaje original-----
De: seminario-de-re...@googlegroups.com
[mailto:seminario-de-re...@googlegroups.com]En nombre de
Juan Pablo Eguinlian
Enviado el: s�bado, 12 de diciembre de 2009 20:28
Para: SEMINARIO DE REDES - TP FINAL
Asunto: LONGITUD DE ARCHIVO
A ra�z de la respuesta que envio Nicol�s, creemos es necesaria la
inclusi�n de un campo que contenga el tama�o en bytes del archivo a
enviar.
Este campo se propone insertarlo en la aplicaci�n del cliente al
momento de solicitar un PUT:
PUT �nombre_archivo� v�n�mero_version� "Tama�o en bytes""\n"
�USER�"\n"
�PASS�"\n"
"\n"
�DATOS���.. EOF�"\n"
En tanto la aplicaci�n del servidor al responder la solicitud de GET
por parte del cliente, responder�:
"STATUS xxx" �nombre_archivo� "Tama�o en bytes""\n"
"\n"
�DATOS���.. EOF�"\n"
En caso de bajarse el archivo de manera incompleta, tanto el server
descartar� el archivo y enviar� un c�digo de error. en caso de
producirse un corte en la conexi�n se detectar� de igual manera y
tambi�n se descartar� el archivo.
En cuanto a las longitudes en los campos m�ximas se propones limitar:
Nombre del archivo-----------15 caracteres
Usuario----------------------------10 caracteres
password-------------------------10 caractreres
Si el nombre de un archivo enviado por un cliente, coincide con el
nombre de uno de los archivos existentes en el servidor. Este enviar�
Usuario----------------------------10 caracteres
password-------------------------10 caractreres
Si el nombre de un archivo enviado por un cliente, coincide con el
un c�digo de error para que el cliente renombre el archivo y cortar�
la conexion. En caso contrario se sobrescribiria el archivo, perdiendo
el original.
Habr�a que especificar una longitud m�xima de archivos a transferir de
el original.
modo de evitar que un usuario se adue�e de la conexi�n.
Saludos!
Ramiro Alonso
Dec 13, 2009, 10:00:15 AM12/13/09
to seminario-de-re...@googlegroups.com
ese dato es a continuacion de la primer linea. Yo creo que conviene
hacer una nueva linea que tenga la siguiente forma
SIZE xxx /n
Donde xxx es el tama�o en bytes.
Es solo mi opinion, creo que ibamos a hacer varias lineas con el nombre
de lo que iba en cada linea para que sea mas facil de escalar el protocolo.
Hay que discutirlo un poco.
Con este agregado estariamos en la version v1.1???
Otra cosa, al final el mensaje terminaba con el EOF??
Saludos,
Ramiro
Moretti Nicolas
Dec 13, 2009, 10:36:38 AM12/13/09
to seminario-de-re...@googlegroups.com
Me parece que Ramiro tiene raz�n, el tama�o tiene que ser incorporado en una
l�nea
nueva.
�les parece que venga despu�s de password?
Quedando:
PUT �nombre_archivo� v�n�mero_version� "\n"
En cuanto al "\n" despu�s del EOF ya se hab�a hablado y se elimino.
Seg�n la RFC la versi�n aumenta de a 1, creo que ya vamos por la 4 o 5.
En cuanto a la respuesta del servidor ante un pedido de get, se propuso
"STATUS xxx" �nombre_archivo� "Tama�o en bytes""\n"
"\n"
�DATOS���.. EOF�"\n"
Lo cambiaria por:
"STATUS" "xxx""\n"
�nombre_archivo�"\n"
Siendo que al analizar la primera l�nea es un status com�n y seg�n el c�digo
"xxx" (que es un string) se puede interpretar si es un status de un get u
otro status
Por eso propongo, que "xxx" se reemplazado por GET, es decir
"STATUS" GET"\n"
�nombre_archivo�"\n"
Agregar�a los siguientes errores
507 Error: Ya existe un archivo con ese nombre
409 Error: No se pudo descargar el archivo en su totalidad
saludos
l�nea
nueva.
�les parece que venga despu�s de password?
Quedando:
PUT �nombre_archivo� v�n�mero_version� "\n"
�USER�"\n"
�PASS�"\n"
"longitud""\n"
�PASS�"\n"
"\n"
�DATOS���.. EOF�
Donde longitud es el tama�o en bytes del archivo expresado como string.
�DATOS���.. EOF�
En cuanto al "\n" despu�s del EOF ya se hab�a hablado y se elimino.
Seg�n la RFC la versi�n aumenta de a 1, creo que ya vamos por la 4 o 5.
En cuanto a la respuesta del servidor ante un pedido de get, se propuso
"STATUS xxx" �nombre_archivo� "Tama�o en bytes""\n"
"\n"
�DATOS���.. EOF�"\n"
"STATUS" "xxx""\n"
�nombre_archivo�"\n"
"Tama�o en bytes""\n"
"\n"
�DATOS���.. EOF�
Lo veo mas practico al tiempo de programar...
"\n"
�DATOS���.. EOF�
Siendo que al analizar la primera l�nea es un status com�n y seg�n el c�digo
"xxx" (que es un string) se puede interpretar si es un status de un get u
otro status
Por eso propongo, que "xxx" se reemplazado por GET, es decir
"STATUS" GET"\n"
�nombre_archivo�"\n"
"Tama�o en bytes""\n"
"\n"
�DATOS���...EOF�
"\n"
Agregar�a los siguientes errores
507 Error: Ya existe un archivo con ese nombre
409 Error: No se pudo descargar el archivo en su totalidad
saludos
Edgardo Dewey
Dec 13, 2009, 12:26:51 PM12/13/09
to seminario-de-re...@googlegroups.com
Estimados,
investigando un poco encontramos que es bastante importante conocer el tamaño de la informaciòn (header,datos) a enviar/recibir (para las funciones recv y send y/o read y write). Es por esto que proponemos el siguiente mecanismo:
/--------------------------- GET -----------------------------------------/
El Cliente solicita un archivo al servidor de la siguiente manera:
----------------------------------------------------------------
| Tamaño | GET | | nombre | | version | \n |
| Header (2B) | (3B)| (1B) | archivo (15B)|(1B) | (2B) |(2B)|
----------------------------------------------------------------
| usuario (10B) | \n |
| |(2B)|
| Tamaño | GET | | nombre | | version | \n |
| Header (2B) | (3B)| (1B) | archivo (15B)|(1B) | (2B) |(2B)|
----------------------------------------------------------------
| usuario (10B) | \n |
| |(2B)|
----------------------------------------------------------------
| password (10B) | \n |
| |(2B)|
----------------------------------------------------------------
| \n |
| (2B) |
----------
| password (10B) | \n |
| |(2B)|
----------------------------------------------------------------
| \n |
| (2B) |
----------
Incluimos un campo donde se indica el tamaño del header (en Bytes) de manera de poder diferenciarlo de los datos.
A lo cual el servidor responderá con el siguiente paquete:
--------------------------------------------
| Tamaño | STATUS XXX | \n |
| Header (2B) | (10B) |(2B)|
--------------------------------------------
| nombre archivo | \n |
| (15B) |(2B)|
--------------------------------------------
| Tamaño de archivo | \n |
| (5B) |(2B)|
--------------------------------------------
| \n | Payload... |
| (2B)| (10240B) |
--------------------------------------------
| Tamaño | STATUS XXX | \n |
| Header (2B) | (10B) |(2B)|
--------------------------------------------
| nombre archivo | \n |
| (15B) |(2B)|
--------------------------------------------
| Tamaño de archivo | \n |
| (5B) |(2B)|
--------------------------------------------
| \n | Payload... |
| (2B)| (10240B) |
--------------------------------------------
Status XXX, siendo XXX el còdigo de error.
Limitamos el tamaño del archivo a 10M.
/--------------------------- PUT -----------------------------------------/
El cliente envia:
----------------------------------------------------------------
| Tamaño | PUT | | nombre | | version | \n |
| Header (2B) | (3B)| (1B) | archivo (15B)|(1B) | (2B) |(2B)|
----------------------------------------------------------------
| usuario (10B) | \n |
| |(2B)|
| Tamaño | PUT | | nombre | | version | \n |
| Header (2B) | (3B)| (1B) | archivo (15B)|(1B) | (2B) |(2B)|
----------------------------------------------------------------
| usuario (10B) | \n |
| |(2B)|
----------------------------------------------------------------
| password (10B) | \n |
| |(2B)|
----------------------------------------------------------------
| password (10B) | \n |
| |(2B)|
----------------------------------------------------------------
| \n | Payload... |
| (2B) | |
----------------------------------------------------------------
| (2B) | |
----------------------------------------------------------------
El servidor responderá:
--------------------------------------------
| Tamaño | STATUS XXX | \n |
| Header (2B) | (10B) |(2B)|
--------------------------------------------
| Tamaño | STATUS XXX | \n |
| Header (2B) | (10B) |(2B)|
--------------------------------------------
El tamaño de cada campo lo asignamos segùn:
Nombre del archivo-----------15 caracteres
Usuario----------------------------10 caracteres
password-------------------------10 caractreres
Usuario----------------------------10 caracteres
password-------------------------10 caractreres
Con estos valores máximos el tamaño del header no superará los 99 caracteres. Es por esto que se determino el tamaño del header en 2Bytes.
Por otra parte consideramos conveniente que el tamaño del PDU sea 2 bytes para reconocer el campo "Tamaño header" más fácilmente.
Còdigos de errores para el status propuestos:
40X Códigos de ERROR del lado del Cliente:
Códigos locales:
Códigos locales:
401 Error: sintaxis. (Refiere a error en el formato de la solicitud)
402 Error: largo de usuario, contraseña o archivo incorrecto. (Si se presentan caracteres inválidos)
402 Error: largo de usuario, contraseña o archivo incorrecto. (Si se presentan caracteres inválidos)
403 Error: disco lleno. (Por si pido un archivo y no queda espacio en el disco rígido local.)
404 Error: Petición No implementada (Si se envía una petición diferente a Get o Put)
405 Error: Vencido el tiempo de solicitud
406 Error: No puede establecerse la conexión
405 Error: Vencido el tiempo de solicitud
406 Error: No puede establecerse la conexión
407 Error: No se puede encontrar el servidor
408 Error: Archivo mayor a tamaño maximo
50x: Códigos de error del lado del Servidor:
Codigos remotos(va al cliente):
Codigos remotos(va al cliente):
501 Error: usuario o contraseña incorrecto
502 Error: archivo no encontrado
503 Error: agotado espacio en disco
504 Error: sin permiso para escribir
505 Error: Versión no soportado
502 Error: archivo no encontrado
503 Error: agotado espacio en disco
504 Error: sin permiso para escribir
505 Error: Versión no soportado
506 Error: Vencido el tiempo de espera (cuando recibe un PUT).
El 13 de diciembre de 2009 12:36, Moretti Nicolas <mon...@gmail.com> escribió:
Me parece que Ramiro tiene razón, el tamaño tiene que ser incorporado en una
línea
nueva.
¿les parece que venga después de password?
Quedando:
PUT “nombre_archivo” v”número_version” "\n"
“USER”"\n"
“PASS”"\n"
"longitud""\n"
"\n"
“DATOS……….. EOF”
Donde longitud es el tamaño en bytes del archivo expresado como string.
En cuanto al "\n" después del EOF ya se había hablado y se elimino.
Según la RFC la versión aumenta de a 1, creo que ya vamos por la 4 o 5.
En cuanto a la respuesta del servidor ante un pedido de get, se propuso
"STATUS xxx" “nombre_archivo” "Tamaño en bytes""\n"
"\n"
“DATOS……….. EOF”"\n"
Lo cambiaria por:
"STATUS" "xxx""\n"
“nombre_archivo”"\n"
"Tamaño en bytes""\n"
"\n"
“DATOS……….. EOF”
Lo veo mas practico al tiempo de programar...
Siendo que al analizar la primera línea es un status común y según el código
"xxx" (que es un string) se puede interpretar si es un status de un get u
otro status
Por eso propongo, que "xxx" se reemplazado por GET, es decir
"STATUS" GET"\n"
“nombre_archivo”"\n"
"Tamaño en bytes""\n"
"\n"
“DATOS………...EOF”Agregaría los siguientes errores
Ramiro Alonso
Dec 13, 2009, 3:20:12 PM12/13/09
to seminario-de-re...@googlegroups.com
Edgardo Dewey wrote:
> Estimados,
>
> investigando un poco encontramos que es bastante importante conocer el
> tama�o de la informaci�n (header,datos) a enviar/recibir (para las
> Estimados,
>
> investigando un poco encontramos que es bastante importante conocer el
> funciones recv y send y/o read y write). Es por esto que proponemos el
> siguiente mecanismo:
>
> /--------------------------- GET
> -----------------------------------------/
>
> El Cliente solicita un archivo al servidor de la siguiente manera:
>
> ----------------------------------------------------------------
> | Tama�o | GET | | nombre | | version | \n |
> siguiente mecanismo:
>
> /--------------------------- GET
> -----------------------------------------/
>
> El Cliente solicita un archivo al servidor de la siguiente manera:
>
> ----------------------------------------------------------------
> | Header (2B) | (3B)| (1B) | archivo (15B)|(1B) | (2B) |(2B)|
> ----------------------------------------------------------------
> | usuario (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | password (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | \n |
> | (2B) |
> ----------
>
> Incluimos un campo donde se indica el tama�o del header (en Bytes) de
> ----------------------------------------------------------------
> | usuario (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | password (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | \n |
> | (2B) |
> ----------
>
> manera de poder diferenciarlo de los datos.
>
> A lo cual el servidor responder� con el siguiente paquete:
>
> --------------------------------------------
> | Tama�o | STATUS XXX | \n |
> | Header (2B) | (10B) |(2B)|
> --------------------------------------------
> | nombre archivo | \n |
> | (15B) |(2B)|
> --------------------------------------------
> | Tama�o de archivo | \n |
> --------------------------------------------
> | nombre archivo | \n |
> | (15B) |(2B)|
> --------------------------------------------
> | (5B) |(2B)|
> --------------------------------------------
> | \n | Payload... |
> | (2B)| (10240B) |
> --------------------------------------------
>
> Status XXX, siendo XXX el c�digo de error.
> --------------------------------------------
> | \n | Payload... |
> | (2B)| (10240B) |
> --------------------------------------------
>
> Limitamos el tama�o del archivo a 10M.
>
>
> /--------------------------- PUT
> -----------------------------------------/
>
> El cliente envia:
> ----------------------------------------------------------------
> | Tama�o | PUT | | nombre | | version | \n |
>
> /--------------------------- PUT
> -----------------------------------------/
>
> El cliente envia:
> ----------------------------------------------------------------
> | Header (2B) | (3B)| (1B) | archivo (15B)|(1B) | (2B) |(2B)|
> ----------------------------------------------------------------
> | usuario (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | password (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | \n | Payload... |
> | (2B) | |
> ----------------------------------------------------------------
>
> El servidor responder�:
> ----------------------------------------------------------------
> | usuario (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | password (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | \n | Payload... |
> | (2B) | |
> ----------------------------------------------------------------
>
> --------------------------------------------
> | Tama�o | STATUS XXX | \n |
> | Header (2B) | (10B) |(2B)|
> --------------------------------------------
>
> El tama�o de cada campo lo asignamos seg�n:
> --------------------------------------------
>
> Nombre del archivo-----------15 caracteres
> Usuario----------------------------10 caracteres
> password-------------------------10 caractreres
>
> Con estos valores m�ximos el tama�o del header no superar� los 99
> Usuario----------------------------10 caracteres
> password-------------------------10 caractreres
>
> caracteres. Es por esto que se determino el tama�o del header en 2Bytes.
> Por otra parte consideramos conveniente que el tama�o del PDU sea 2
> bytes para reconocer el campo "Tama�o header" m�s f�cilmente.
>
> C�digos de errores para el status propuestos:
>
> _40X C�digos de ERROR del lado del Cliente_:
> C�digos locales:
> 401 Error: sintaxis. (Refiere a error en el formato de la solicitud)
> 402 Error: largo de usuario, contrase�a o archivo incorrecto. (Si se
> presentan caracteres inv�lidos)
> 403 Error: disco lleno. (Por si pido un archivo y no queda espacio en
> el disco r�gido local.)
> 404 Error: Petici�n No implementada (Si se env�a una petici�n
> diferente a Get o Put)
> 405 Error: Vencido el tiempo de solicitud
> 406 Error: No puede establecerse la conexi�n
> 405 Error: Vencido el tiempo de solicitud
> 407 Error: No se puede encontrar el servidor
> 408 Error: Archivo mayor a tama�o maximo
>
> _50x: C�digos de error del lado del Servidor:_
> Codigos remotos(va al cliente):
> 501 Error: usuario o contrase�a incorrecto
> 502 Error: archivo no encontrado
> 503 Error: agotado espacio en disco
> 504 Error: sin permiso para escribir
> 505 Error: Versi�n no soportado
> 503 Error: agotado espacio en disco
> 504 Error: sin permiso para escribir
> 506 Error: Vencido el tiempo de espera (cuando recibe un PUT).
>
>
>
>
> El 13 de diciembre de 2009 12:36, Moretti Nicolas <mon...@gmail.com
> <mailto:mon...@gmail.com>> escribi�:
>
>
>
>
> El 13 de diciembre de 2009 12:36, Moretti Nicolas <mon...@gmail.com
>
> Me parece que Ramiro tiene raz�n, el tama�o tiene que ser
> incorporado en una
> l�nea
> nueva.
>
> �les parece que venga despu�s de password?
>
> Quedando:
>
> PUT �nombre_archivo� v�n�mero_version� "\n"
> �USER�"\n"
> �PASS�"\n"
> "longitud""\n"
> "\n"
> �DATOS���.. EOF�
>
> Donde longitud es el tama�o en bytes del archivo expresado como
> nueva.
>
> �les parece que venga despu�s de password?
>
> Quedando:
>
> PUT �nombre_archivo� v�n�mero_version� "\n"
> �USER�"\n"
> �PASS�"\n"
> "longitud""\n"
> "\n"
> �DATOS���.. EOF�
>
> string.
>
> En cuanto al "\n" despu�s del EOF ya se hab�a hablado y se elimino.
> Seg�n la RFC la versi�n aumenta de a 1, creo que ya vamos por la 4
> o 5.
>
>
> En cuanto a la respuesta del servidor ante un pedido de get, se
> propuso
>
>
>
> En cuanto a la respuesta del servidor ante un pedido de get, se
> propuso
>
> "STATUS xxx" �nombre_archivo� "Tama�o en bytes""\n"
> "\n"
> �DATOS���.. EOF�"\n"
> "\n"
>
> Lo cambiaria por:
>
> "STATUS" "xxx""\n"
> Lo cambiaria por:
>
> "STATUS" "xxx""\n"
> �nombre_archivo�"\n"
> "Tama�o en bytes""\n"
> "\n"
> �DATOS���.. EOF�
>
> "Tama�o en bytes""\n"
> "\n"
> �DATOS���.. EOF�
>
> Lo veo mas practico al tiempo de programar...
> Siendo que al analizar la primera l�nea es un status com�n y seg�n
> el c�digo
> el c�digo
> "xxx" (que es un string) se puede interpretar si es un status de
> un get u
> otro status
> Por eso propongo, que "xxx" se reemplazado por GET, es decir
>
> "STATUS" GET"\n"
> un get u
> otro status
> Por eso propongo, que "xxx" se reemplazado por GET, es decir
>
> "STATUS" GET"\n"
> �nombre_archivo�"\n"
> "Tama�o en bytes""\n"
> "\n"
> �DATOS���...EOF�
>
> Agregar�a los siguientes errores
> "Tama�o en bytes""\n"
> "\n"
> �DATOS���...EOF�
>
>
> 507 Error: Ya existe un archivo con ese nombre
>
> 409 Error: No se pudo descargar el archivo en su totalidad
>
>
>
> saludos
>
>
>
>
Devuelta, no conviene que la longitud del header vaya en una linea
> 507 Error: Ya existe un archivo con ese nombre
>
> 409 Error: No se pudo descargar el archivo en su totalidad
>
>
>
> saludos
>
>
>
>
nueva? De esta forma no modificamos la primer linea, y simplificamos la
programacion.
Edgardo Dewey
Dec 13, 2009, 3:33:01 PM12/13/09
to seminario-de-re...@googlegroups.com
El problema sería que desconocemos la longitud de la primer línea, ya que la longitud del campo de nombre del archivo, es variable..
En cambio si sabemos que los dos primeros bytes indican la longitud del header, ya tenemos cuanta memoria reservar para almacenar el header y después parcearlo..
Edgardo nicolas Moretti
Dec 13, 2009, 3:33:17 PM12/13/09
to seminario-de-re...@googlegroups.com
Sr Dewey:
Muy interesante su aporte, pero que le puedo decir me gusta mas la forma que propuse antes.
En cuanto a los errores progongo los siguientes:
401 Error: sintaxis. (Refiere a error en el formato de la solicitud)
402 Error: largo de usuario, contraseña o archivo incorrecto.
403 Error: disco lleno. (Por si pido un archivo y no queda espacio en el disco rígido local.)
404 Error: versión incompatible
405 Error: Petición No implementada (Si se envía una petición diferente a Get o Put)
406 Error: Vencido el tiempo de solicitud
407 Error: No puede establecerse la conexión
408 Error: No se puede encontrar el servidor
501 Error: usuario o contraseña incorrecto
502 Error: archivo no encontrado
503 Error: agotado espacio en disco
504 Error: sin permiso para escribir
505 Error: sin permiso para leer
506 Error: Petición No implementada (por si pasan una petición diferente a Get o Put)
507 Error: Versión no soportada
508 Error: Ya existe un archivo con ese nombre
509 Error: Vencio el tiempo de respuesta del Cliente
510 Error: No se pudo abrir la base de datos (donde se guarda el usuario y passwr)
El 13 de diciembre de 2009 17:20, Ramiro Alonso <ninja...@gmail.com> escribió:
Edgardo Dewey wrote:
Estimados,
investigando un poco encontramos que es bastante importante conocer el tamaño de la informaciòn (header,datos) a enviar/recibir (para las funciones recv y send y/o read y write). Es por esto que proponemos el siguiente mecanismo:
/--------------------------- GET -----------------------------------------/
El Cliente solicita un archivo al servidor de la siguiente manera:
----------------------------------------------------------------
| Tamaño | GET | | nombre | | version | \n |
| Header (2B) | (3B)| (1B) | archivo (15B)|(1B) | (2B) |(2B)|
----------------------------------------------------------------
| usuario (10B) | \n |
| |(2B)|
----------------------------------------------------------------
| password (10B) | \n |
| |(2B)|
----------------------------------------------------------------
| \n |
| (2B) |
----------
Incluimos un campo donde se indica el tamaño del header (en Bytes) de manera de poder diferenciarlo de los datos.
A lo cual el servidor responderá con el siguiente paquete:
--------------------------------------------
| Tamaño | STATUS XXX | \n |
| Header (2B) | (10B) |(2B)|
--------------------------------------------
| nombre archivo | \n |
| (15B) |(2B)|
--------------------------------------------
| Tamaño de archivo | \n |
| (5B) |(2B)|
--------------------------------------------
| \n | Payload... | | (2B)| (10240B) |
--------------------------------------------
Status XXX, siendo XXX el còdigo de error.
Limitamos el tamaño del archivo a 10M.
/--------------------------- PUT -----------------------------------------/
El cliente envia:
----------------------------------------------------------------
| Tamaño | PUT | | nombre | | version | \n |
| Header (2B) | (3B)| (1B) | archivo (15B)|(1B) | (2B) |(2B)|
----------------------------------------------------------------
| usuario (10B) | \n |
| |(2B)|
----------------------------------------------------------------
| password (10B) | \n |
| |(2B)|
----------------------------------------------------------------
| \n | Payload... | | (2B) | |
----------------------------------------------------------------
El servidor responderá:
--------------------------------------------
| Tamaño | STATUS XXX | \n |
| Header (2B) | (10B) |(2B)|
--------------------------------------------
El tamaño de cada campo lo asignamos segùn:
Nombre del archivo-----------15 caracteres
Usuario----------------------------10 caracteres
password-------------------------10 caractreres
Con estos valores máximos el tamaño del header no superará los 99 caracteres. Es por esto que se determino el tamaño del header en 2Bytes.
Por otra parte consideramos conveniente que el tamaño del PDU sea 2 bytes para reconocer el campo "Tamaño header" más fácilmente.
Còdigos de errores para el status propuestos:
_40X Códigos de ERROR del lado del Cliente_:
Códigos locales:
401 Error: sintaxis. (Refiere a error en el formato de la solicitud)
402 Error: largo de usuario, contraseña o archivo incorrecto. (Si se presentan caracteres inválidos)
403 Error: disco lleno. (Por si pido un archivo y no queda espacio en el disco rígido local.)
404 Error: Petición No implementada (Si se envía una petición diferente a Get o Put)
405 Error: Vencido el tiempo de solicitud
406 Error: No puede establecerse la conexión
407 Error: No se puede encontrar el servidor
408 Error: Archivo mayor a tamaño maximo _50x: Códigos de error del lado del Servidor:_
Codigos remotos(va al cliente):
501 Error: usuario o contraseña incorrecto
502 Error: archivo no encontrado
503 Error: agotado espacio en disco
504 Error: sin permiso para escribir
505 Error: Versión no soportado
506 Error: Vencido el tiempo de espera (cuando recibe un PUT).
El 13 de diciembre de 2009 12:36, Moretti Nicolas <mon...@gmail.com <mailto:mon...@gmail.com>> escribió:
Me parece que Ramiro tiene razón, el tamaño tiene que ser
incorporado en una
línea
nueva.
¿les parece que venga después de password?
Quedando:
PUT “nombre_archivo” v”número_version” "\n"
“USER”"\n"
“PASS”"\n"
"longitud""\n"
"\n"
“DATOS……….. EOF”
Donde longitud es el tamaño en bytes del archivo expresado como
string.
En cuanto al "\n" después del EOF ya se había hablado y se elimino.
Según la RFC la versión aumenta de a 1, creo que ya vamos por la 4
o 5.
En cuanto a la respuesta del servidor ante un pedido de get, se
propuso
"STATUS xxx" “nombre_archivo” "Tamaño en bytes""\n"
"\n"
“DATOS……….. EOF”"\n"
Lo cambiaria por:
"STATUS" "xxx""\n"
“nombre_archivo”"\n"
"Tamaño en bytes""\n"
"\n"
“DATOS……….. EOF”
Lo veo mas practico al tiempo de programar...
Siendo que al analizar la primera línea es un status común y según
el código
"xxx" (que es un string) se puede interpretar si es un status de
un get u
otro status
Por eso propongo, que "xxx" se reemplazado por GET, es decir
"STATUS" GET"\n"
“nombre_archivo”"\n"
"Tamaño en bytes""\n"
"\n"
“DATOS………...EOF”
Agregaría los siguientes errores
507 Error: Ya existe un archivo con ese nombre
409 Error: No se pudo descargar el archivo en su totalidad
saludos
Ramiro Alonso
Dec 13, 2009, 4:11:27 PM12/13/09
to seminario-de-re...@googlegroups.com
Edgardo nicolas Moretti wrote:
>
> Sr Dewey:
> Muy interesante su aporte, pero que le puedo decir me gusta mas
> la forma que propuse antes.
>
> En cuanto a los errores progongo los siguientes:
>
> 401 Error: sintaxis. (Refiere a error en el formato de la solicitud)
>
> 402 Error: largo de usuario, contrase�a o archivo incorrecto.
>
> Sr Dewey:
> Muy interesante su aporte, pero que le puedo decir me gusta mas
> la forma que propuse antes.
>
> En cuanto a los errores progongo los siguientes:
>
> 401 Error: sintaxis. (Refiere a error en el formato de la solicitud)
>
> 403 Error: disco lleno. (Por si pido un archivo y no queda espacio en el disco r�gido local.)
> 404 Error: versi�n incompatible
> 405 Error: Petici�n No implementada (Si se env�a una petici�n diferente a Get o Put)
>
> 406 Error: Vencido el tiempo de solicitud
> 407 Error: No puede establecerse la conexi�n
> 406 Error: Vencido el tiempo de solicitud
> 408 Error: No se puede encontrar el servidor
>
> 501 Error: usuario o contrase�a incorrecto
>
> 502 Error: archivo no encontrado
>
> 503 Error: agotado espacio en disco
> 504 Error: sin permiso para escribir
> 505 Error: sin permiso para leer
>
> 506 Error: Petici�n No implementada (por si pasan una petici�n diferente a Get o Put)
>
> 503 Error: agotado espacio en disco
> 504 Error: sin permiso para escribir
> 505 Error: sin permiso para leer
>
> 507 Error: Versi�n no soportada
> 508 Error: Ya existe un archivo con ese nombre
> 509 Error: Vencio el tiempo de respuesta del Cliente
>
> 510 Error: No se pudo abrir la base de datos (donde se guarda el usuario y passwr)
>
>
>
>
> El 13 de diciembre de 2009 17:20, Ramiro Alonso <ninja...@gmail.com
> <mailto:ninja...@gmail.com>> escribi�:
> 509 Error: Vencio el tiempo de respuesta del Cliente
>
> 510 Error: No se pudo abrir la base de datos (donde se guarda el usuario y passwr)
>
>
>
>
> El 13 de diciembre de 2009 17:20, Ramiro Alonso <ninja...@gmail.com
>
> Edgardo Dewey wrote:
>
> Estimados,
> investigando un poco encontramos que es bastante importante
> conocer el tama�o de la informaci�n (header,datos) a
> Edgardo Dewey wrote:
>
> Estimados,
> investigando un poco encontramos que es bastante importante
> enviar/recibir (para las funciones recv y send y/o read y
> write). Es por esto que proponemos el siguiente mecanismo:
> /--------------------------- GET
> -----------------------------------------/
> El Cliente solicita un archivo al servidor de la siguiente
> manera:
> ----------------------------------------------------------------
> | Tama�o | GET | | nombre | | version | \n |
> write). Es por esto que proponemos el siguiente mecanismo:
> /--------------------------- GET
> -----------------------------------------/
> El Cliente solicita un archivo al servidor de la siguiente
> manera:
> ----------------------------------------------------------------
> | Header (2B) | (3B)| (1B) | archivo (15B)|(1B) | (2B) |(2B)|
> ----------------------------------------------------------------
> | usuario (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | password (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | \n |
> | (2B) |
> ----------
> Incluimos un campo donde se indica el tama�o del header (en
> ----------------------------------------------------------------
> | usuario (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | password (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | \n |
> | (2B) |
> ----------
> Bytes) de manera de poder diferenciarlo de los datos.
> A lo cual el servidor responder� con el siguiente paquete:
> --------------------------------------------
> | Tama�o | STATUS XXX | \n |
> | Header (2B) | (10B) |(2B)|
> --------------------------------------------
> | nombre archivo | \n |
> | (15B) |(2B)|
> --------------------------------------------
> | Tama�o de archivo | \n |
> --------------------------------------------
> | nombre archivo | \n |
> | (15B) |(2B)|
> --------------------------------------------
> | (5B) |(2B)|
> --------------------------------------------
> | \n | Payload... | | (2B)|
> (10240B) |
> --------------------------------------------
> --------------------------------------------
> | \n | Payload... | | (2B)|
> (10240B) |
> --------------------------------------------
> Status XXX, siendo XXX el c�digo de error.
> Limitamos el tama�o del archivo a 10M.
> /--------------------------- PUT
> -----------------------------------------/
> El cliente envia:
> ----------------------------------------------------------------
> | Tama�o | PUT | | nombre | | version | \n |
> -----------------------------------------/
> El cliente envia:
> ----------------------------------------------------------------
> | Header (2B) | (3B)| (1B) | archivo (15B)|(1B) | (2B) |(2B)|
> ----------------------------------------------------------------
> | usuario (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | password (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | \n | Payload...
> | | (2B) | |
> ----------------------------------------------------------------
> El servidor responder�:
> ----------------------------------------------------------------
> | usuario (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | password (10B) | \n |
> | |(2B)|
> ----------------------------------------------------------------
> | \n | Payload...
> | | (2B) | |
> ----------------------------------------------------------------
> --------------------------------------------
> | Tama�o | STATUS XXX | \n |
> | Header (2B) | (10B) |(2B)|
> --------------------------------------------
> El tama�o de cada campo lo asignamos seg�n:
> --------------------------------------------
> Nombre del archivo-----------15 caracteres
> Usuario----------------------------10 caracteres
> password-------------------------10 caractreres
> Usuario----------------------------10 caracteres
> password-------------------------10 caractreres
> Con estos valores m�ximos el tama�o del header no superar�
> los 99 caracteres. Es por esto que se determino el tama�o del
> header en 2Bytes.
> Por otra parte consideramos conveniente que el tama�o del PDU
> sea 2 bytes para reconocer el campo "Tama�o header" m�s
> f�cilmente.
> C�digos de errores para el status propuestos:
> sea 2 bytes para reconocer el campo "Tama�o header" m�s
> f�cilmente.
> _40X C�digos de ERROR del lado del Cliente_:
> C�digos locales:
> 401 Error: sintaxis. (Refiere a error en el formato de la
> solicitud)
> 402 Error: largo de usuario, contrase�a o archivo incorrecto.
> solicitud)
> (Si se presentan caracteres inv�lidos)
> 403 Error: disco lleno. (Por si pido un archivo y no queda
> espacio en el disco r�gido local.)
> 404 Error: Petici�n No implementada (Si se env�a una petici�n
> 404 Error: Petici�n No implementada (Si se env�a una petici�n
> diferente a Get o Put)
> 405 Error: Vencido el tiempo de solicitud
> 406 Error: No puede establecerse la conexi�n
> 405 Error: Vencido el tiempo de solicitud
> 407 Error: No se puede encontrar el servidor
> 408 Error: Archivo mayor a tama�o maximo _50x: C�digos de
> error del lado del Servidor:_
> Codigos remotos(va al cliente):
> 501 Error: usuario o contrase�a incorrecto
> Codigos remotos(va al cliente):
> 502 Error: archivo no encontrado
> 503 Error: agotado espacio en disco
> 504 Error: sin permiso para escribir
> 505 Error: Versi�n no soportado
> 503 Error: agotado espacio en disco
> 504 Error: sin permiso para escribir
> 506 Error: Vencido el tiempo de espera (cuando recibe un PUT).
> El 13 de diciembre de 2009 12:36, Moretti Nicolas
> <mon...@gmail.com <mailto:mon...@gmail.com>
> <mailto:mon...@gmail.com <mailto:mon...@gmail.com>>> escribi�:
> El 13 de diciembre de 2009 12:36, Moretti Nicolas
> <mon...@gmail.com <mailto:mon...@gmail.com>
>
>
> Me parece que Ramiro tiene raz�n, el tama�o tiene que ser
> incorporado en una
> l�nea
> nueva.
>
> �les parece que venga despu�s de password?
>
> Quedando:
>
> PUT �nombre_archivo� v�n�mero_version� "\n"
> �USER�"\n"
> �PASS�"\n"
> "longitud""\n"
> "\n"
> �DATOS���.. EOF�
>
> Donde longitud es el tama�o en bytes del archivo expresado como
> nueva.
>
> �les parece que venga despu�s de password?
>
> Quedando:
>
> PUT �nombre_archivo� v�n�mero_version� "\n"
> �USER�"\n"
> �PASS�"\n"
> "longitud""\n"
> "\n"
> �DATOS���.. EOF�
>
> string.
>
> En cuanto al "\n" despu�s del EOF ya se hab�a hablado y se
> elimino.
> Seg�n la RFC la versi�n aumenta de a 1, creo que ya vamos
> elimino.
> por la 4
> o 5.
>
>
> En cuanto a la respuesta del servidor ante un pedido de get, se
> propuso
>
> o 5.
>
>
> En cuanto a la respuesta del servidor ante un pedido de get, se
> propuso
>
> "STATUS xxx" �nombre_archivo� "Tama�o en bytes""\n"
> "\n"
> �DATOS���.. EOF�"\n"
> "\n"
>
> Lo cambiaria por:
>
> "STATUS" "xxx""\n"
> Lo cambiaria por:
>
> "STATUS" "xxx""\n"
> �nombre_archivo�"\n"
> "Tama�o en bytes""\n"
> "\n"
> �DATOS���.. EOF�
>
> "Tama�o en bytes""\n"
> "\n"
> �DATOS���.. EOF�
>
> Lo veo mas practico al tiempo de programar...
> Siendo que al analizar la primera l�nea es un status com�n
> y seg�n
> el c�digo
> y seg�n
> el c�digo
> "xxx" (que es un string) se puede interpretar si es un
> status de
> un get u
> otro status
> Por eso propongo, que "xxx" se reemplazado por GET, es decir
>
> "STATUS" GET"\n"
> status de
> un get u
> otro status
> Por eso propongo, que "xxx" se reemplazado por GET, es decir
>
> "STATUS" GET"\n"
> �nombre_archivo�"\n"
> "Tama�o en bytes""\n"
> "\n"
> �DATOS���...EOF�
>
> Agregar�a los siguientes errores
> "Tama�o en bytes""\n"
> "\n"
> �DATOS���...EOF�
>
>
> 507 Error: Ya existe un archivo con ese nombre
>
> 409 Error: No se pudo descargar el archivo en su totalidad
>
>
>
> saludos
>
>
>
>
> Devuelta, no conviene que la longitud del header vaya en una linea
> nueva? De esta forma no modificamos la primer linea, y
> simplificamos la programacion.
>
>
Me suena raro que empiece a recibir informaci�n con el tama�o. Incluso
> 507 Error: Ya existe un archivo con ese nombre
>
> 409 Error: No se pudo descargar el archivo en su totalidad
>
>
>
> saludos
>
>
>
>
> Devuelta, no conviene que la longitud del header vaya en una linea
> nueva? De esta forma no modificamos la primer linea, y
> simplificamos la programacion.
>
>
antes que el GET.
El tama�o del encabezado viene especificado con la versi�n del
protocolo. uno sabe que lineas tiene que recibir y el m�ximo tama�o que
pueden ocupar, podr�a ser informaci�n redundante.
En mi opinion, el encabezado no se tendria que modificar antes del
numero de versi�n, pero bueno, hay que discutirlo. Si les parece lo ponemos.
Saludos
Reply all
Reply to author
Forward
0 new messages