Názory k článku Sokety a C/C++: Urgentní data

Zajimalo by mne, jak se skrze http prenasi bin soubory. V RFC je zminka, ze je to trochu podobne MIME, ale zase ne az tak uplne. V cem je tedy rozdil, nebo co se vklada? Zatim se mi podarilo zjistit (z kodu) jen, ze pred '0D' je vkladan jeste jeden znak '0D'. Je to vsechno, nebo je toho vic a podle jakych pravidel?
Diky.
M.

Nevim jak jste prisel na tech 0D. Binarni data se prenasi tak, ze se v hlavicce uvede ze se jedna o binarni data - presneji, polozka Context-type se nastavi na MIME typ dat. Vlastni data se nemodifikuji. Pro jistotu jsem si to prave experimentalne overil na obrazku brejlateho chlapka co visi tady na rootovi s pomoci netcatu, ktery SPOLEHLIVE zadnou modifikaci dat neprovadi protoze o HTTP nic nevi.

No, ja to overoval na .exe souboru. To 0D jsem zjistil tak, ze jsem porovnaval obsah toho souboru po prijeti s puvodnim.

Sorry za dlouhý příspěvek, ale v dokumentaci k WinSock 2.2 API v kapitole o OOB jsem našel cosi o problémech s kompatibilitou mezi různými implementacemi socketů a nevím, jak moc se toho mám bát (text prikladam dole). Zatím mám pocit, že bych se OOB radši vyhnul. Ale budu rád, když to někdo vyvrátíte.

Dik,
John

Note: The following discussion of out-of-band (OOB) data, implemented using TCP Urgent data, follows the model used in the Berkeley software distribution. Users and implementors should be aware of the fact that there are at present two conflicting interpretations of RFC 793 (in which the concept is introduced), and that the implementation of out-of-band data in the Berkeley Software Distribution (BSD) does not conform to the Host Requirements laid down in RFC 1122.

Specifically, the TCP urgent pointer in BSD points to the byte after the urgent data byte, and an RFC-compliant TCP urgent pointer points to the urgent data byte. As a result, if an application sends urgent data from a BSD-compatible implementation to an RFC-1122 compatible implementation then the receiver will read the wrong urgent data byte (it will read the byte located after the correct byte in the data stream as the urgent data byte).

To minimize interoperability problems, applications writers are advised not to use out-of-band data unless this is required in order to interoperate with an existing service. Windows Sockets suppliers are urged to document the out-of-band semantics (BSD or RFC 1122) which their product implements.

no o tom se jeste neslysel, ale myslim ze by nemel bejt problem to udelat tak, ze pred kazdy OOB data, ktery posilate, date urcitej jedinecnej retezec, a pri prijeti kontrolujete zda je tam cely retezec nebo jed od druheho znaku, a o tolik posunete vlastni zacatek dat.

imho ale kdyz pisete aplikaci tak vetsinou vite jestli bude komunikovat win2win nebo bsd2bsd,linux nebo nedej boze bsd2win ...

O tom problému jsem už něco slyšel, ale ještě jsem se s ním nesetkal (Možná o to horší to bude, až se s ním opravdu setkám :-) ). Jde o to, že podle starší specifikace normy není jasné, jestli ukazatel na konec urgentních dat (který je součástí hlavičky TCP) má ukazovat na poslední byte urgentních dat, nebo na první byte za posledním bytem urgentních dat.
V každém případě příklady pod článkem fungují i při komuniakci Linux - Win. Linux by měl mít BSD kompatibilní socket API.

Diky za info. IMO Windows i Linux jsou BSD kompatibilni. Shanim tedy nekompatibilni platformu, abych to mohl otestovat meziplatforme :-).

Nejde mi ani tak o OOB data jako spise o signal SIGURG, ktery je snad mozno odchytavat, a kterym bych mohl merit presnou zpozdeni kanalu. Timto kanalem chci zaroven posilat i normalni data.