Dnia 30.07.2015 Sebastian Biały <h...@p...onet.pl> napisał/a:
> On 2015-07-30 22:16, Pit wrote:
>> Gdzie oferują *za darmo*? Bo mi oferują tylko nielimitowane rozmowy przy
>> stałej *opłacie* abonamentowej
>
> W banku płacisz ją w postaci opłaty za konto ROR. Mogę płacić więcej
> jeśli odstanę to co chce. Obecnie opłaty za szybkie przelewy sa
> niekonkurencyjne w stosunku do operatorow prywatnych poza bankami którzy
> czesto pobierają grosze lub nic.

Bo to nie są przelewy tylko *przekazy* (na tej zasadzie Poczta Polska może
też przesłać szybciej kasę niż Elixir, ale to nie przelew choć... Poczta
Polska jest tu jednym z ustawowych wyjątków i przekaz pocztowy ma prawie
taką samą "wartość urzędową/sądową" jak przelew bankowy).

>> A teraz wyobraź sobie, że masz zapewnić, aby każda zmiana dokonana przez
>> każdego ze 100 członków zespołu była automatycznie dystrybuowana do
>> wszystkich pozostałych
>
> Nie do wszystkich. Tylko do pośrednika jakim jest np. KIR czy co tam
> stoi po środku i szpieguje.

No tak, ale zmiana musi pójść nie tylko do KIR ale też do "wszystkich
zainteresowanych". Czyli jeśli ja z banku X wysyłam przelew na twoje konto
w banku Y, to po pierwsze bank X musi to przesłać do KIR, dalej KIR musi to
przesłać do Y, Y potwierdza przyjęcie kasy na Twoje konto odsyłając
odpowiednie info do KIR, KIR "zatwierdza" przelew i wysyła o tym info do X,
X potwierdza przyjęcie "zatwierdzenia", KIR liczy bilans wszystkich
zatwierdzonych przelewów między bankami X-Y od ostatniego "point in time" i
wysyła do NBP polecenie przelewu między kontami banków X-Y (kontami banków,
nie klientów banków).

To musi lecieć w dwie strony, bo chociażby konto docelowe może nie istnieć
(więc przelew "live" nie powinien się udać). Do tego takie firmy jak
BlueCash korzystają z tego, że to system bankowy załatwi 80% roboty za nich
i z tego, że nie są bankami, a więc prawo bankowe ich nie dotyczy (między
innymi obieg przez KIR). Minus jest taki, że mogą obsługiwać tylko małe
płatności. Zresztą, to dla banków żadna konkurencja, bo i tak kasa musi
przejść przez banki (które swoje zarobią :D).

>> wszyscy muszą być praktycznie cały czas podłączeni do repo
>
> Banki nie muszą widzień innych transakcji, w szczególności banki nie
> musza być spięte na stałe kazdy z każdym, wystarczy z koordynatorem.

No przecież to napisałem - nie muszą być spięte z serwerem repo.

> Nikt nie wymaga milisekudowych reakcji. Ale wymagane są reakcje w czasie
> zdroworozsądkowym. Prawdę mowiąc 1h wystarczy. A więc i wystarczy
> pooling raz co godzinę "co tam nowego dla mnie". Oczywiście 1h to lazy
> workaround. Zejscie do kilku minut nie powinno być kłopotem. Innymi
> słowy: hybryda w kierunku częstego wymieniania się informacjami. Jak się
> dokladnie przyglądnąć to wystarczyło by pogonić elixir na kilkanaście
> sesji dziennie i mozna zamknąć mordę takim pieniaczom jak ja. Tylko ten
> Bosman-8 może nie uciągnąć ...

Też jestem zdania, że gdyby pognać elixiry (i przede wszystkim nie robić
sesji przychodzących rano a wychodzących wieczorem) to dałoby się osiągnąć
czas 1-2h (gwarantowany) a tak, to jak wyślę powiedzmy z Milennium przelew
o 8:00, to "wyjdzie" z banku o 11:00 i na przykład w Credit-Agricole
zobaczę go dopiero o 12:00 - tragedia :D Ale jeszcze większa tragedia
polega na tym, że jak zrobię polecenie przelewu w Millenium o 8:30, to ono
"nie zdąży" wyjść sesją o 11:00 tylko wyjdzie dopiero o 15:00. Mało tego,
jak kasa przyjdzie do Millenium sesją przychodzącą o 14:30, to bank to
zaksięguje dopiero po 16:00. Zupełnie nie rozumiem czemu jest taka
latencja księgowania środków w Millenium, skoro na przykład przelewy między
CreditAgricole i mBank takiej latencji w księgowaniu nie mają (w
którąkolwiek stronę), wyślę w Credit-Agricole o 14:15, to wyjdzie w sesji
wychodzącej o 14:30, przyjdzie do mBanku w sesji przychodzącej o 15:00 a o
15:10 mam zaksięgowane na koncie w mBanku. Po prostu, niektóre banki
mająsystemy do dupy i za bardzo popędzić się nie da, w jednym banku
księgowanie przelewów wychodzących czy przychodzących jest praktycznie
natychmiastowe (trwa maksymalnie kilka minut) a w innych bankach trwa kilka
godzin (typu puścisz w Millenium przelew o 15:00, to nie zdąży wyjść sesją
wychodzącą o 17:00 i wydajność systemu KIR nie ma tu nic do rzeczy, ich
"Bosman-8" daje radę, zresztą gdyby sesje elixir robić na przykład co
godzinę, to zawierałyby mniej operacji do zrealizowania - live to by to nie
było, ale przelew w 1-2 godziny byłby ok).

do góry

Dnia 30.07.2015 szemrany <s...@o...off> napisał/a:
> Dzwonię za darmo w tym sensie, że gdy nie dzwonię to nadajnik i tak stoi, i
> tak czerpie energię, i tylko procesor zamiast przetwarzać moje konwersacje
> mieli puste pętle w oczekiwaniu na robotę. Jak dzwonię to nie powoduję
> większego zużycia miedzi w kablach czy krzemu w prockach. Trochę więcej
> prądu idzie, ale nie ma to znaczenia istotnego.

Nie odwracaj kota ogonem. Napisałeś wcześniej (tylko wyciąłeś w tym poście):

|No i będą oferować za darmo, tak jak już oferują rozmowy telefoniczne, gdy
|kiedyś chcieli 2 czy 3 zł za każdą rozpoczętą minutę. Jeszcze chwila.

Pisałeś o *oferowaniu* połączeń za darmo a nie o tym, że koszt utrzymania
BTS-a jest praktycznie stały (niezależnie od tego czy ktoś dzwoni czy nie).
No ale trzymając się Twojej "nowszej wersji": w praktyce nie jest tak jak
piszesz, jeśli z danego BTS-a korzysta ktoś powiedzmy raz dziennie, to
można go pozostawić z kartą obsługującą 4 kanały i mieć święty spokój, ale
jak taki BTS stoi w centrum handlowym, to musi "uciągnąć" co najmniej
kilkadziesiąt równoległych połączeń, więc tych kart z transceiverami trzeba
mu nieco włożyć (albo zastosować znacznie droższy szerokopasmowy SDR/DDS).
Duży ruch *zwiększa* koszt systemu, bo trzeba zapewnić warunki aby go
obsłużyć, a jak tego ruchu w danej chwili nie ma to koszt nie spada - ok,
nie spada, ale to nie to samo, co "koszt jest niezależny od generowanego
ruchu" (bo jest zależny od przepustowości jaką zapewniasz a nie od tego czy
ktoś w danej chwili z tego korzysta czy nie).
Na darmowe połączenia nie masz co liczyć, bo infrastruktura kosztuje nawet
jak nikt nie dzwoni, więc operatorzy muszą zgarnąć kasę na jej utrzymanie
(a że mogą nie rozliczać za minuty, tylko brać stałą kasę za samą
możliwość zadzwonienia to zupełnie inna sprawa, to nie jest "oferowanie
rozmów telefonicznych za darmo").

> W tym wszystkim transmisja głosu czy internet to tylko ficzer, który
> docelowo ma zachęcać do skorzystania i dać szansę sprzedać komercyjną
> usługę dodatkową.

Nie ważne, tak czy siak nie jest "za darmo" bo utrzymanie infrastruktury
kosztuje i w dodatku zapewnienie powiedzmy 10 równoczesnych rozmów z danego
BTS-a jest tańsze niż zapewnienie 100 równoczesnych rozmów. Mówimy o
normalnym GSM, bo w UMTS sprawa jest nieco inna, tam jest stosowany
mechanizm rozpraszania widma i stałej przepustowości, która jest "dzielona"
na poszczególnych użytkowników, czym więcej użytkowników BTS-a, tym każdemu
przypada mniejszy transfer a więc i mniejszy bitrate kodeka mowy itd., no
ale zgoda, w UMTS jest duży "zapas pasma" na rozmowy jeśli akurat nikt nie
"zarzyna" pasma dostępem do internetu, jeszcze szersze jest LTE, ale za to
ma tak tragicznie mały zasięg, że o pokryciu obszarów z małą gęstością
zaludnienia nie ma co marzyć (potrzebne byłyby gęsto umieszczone BTS-y, a
te są drogie i stawianie BTS-a aby korzystało z niego tylko kilku
użytkowników jest nieopłacalne, z drugiej strony nikt nie będzie chodził z
antenami kierunkowymi aby móc zadzwonić gdy znajduje się 5km od
najbliższego BTS-a :D)

> A to, że jeszcze się to aż tak bardzo nie rozwinęło to
> tylko kwestia czasu. Ten model dobrze obrazuje np. Spotify, używasz? Możesz
> sobie za darmo słuchać muzy, ale masz odcięte usługi premium, część ludzi
> jednak chce premium i dopłacają utrzymując system.

Nadal to nie jest za darmo, a że nie Ty za to płacisz, tylko inni (na
przykład użytkownicy premium, albo muzycy chcący się wypromować czy
reklamodawcy) to tylko pozór "darmowości". Wyszukiwarka Google też jest "za
darmo"... dla Ciebie i dla mnie, ale ktoś za jej istnienie płaci i za ten
milion serwerów, które dają potencjalną możliwość obsłużenia milionów
zapytań jednocześnie, a jak się wszyscy na świecie umówią i zrobią "dzień
bez Google", to zgoda, róznica będzie tylko w mniejszym zużyciu prądu.

> Z internetem i
> telefonowaniem jest to trochę opóźnione, bo nie mają dobrych pomysłów jak
> wykorzystać szerzej te możliwości, ale powoli się to zmienia.

Już kilkanaście lat temu byłem jednym z testerów pomysłu operatora (jeszcze
wtedy Ery), że jak nie chcesz płacić za połączenie, to możesz dodać
specjalny kod przed numerem docelowym korespondenta i wtedy po zestawieniu
połączenia była 15 sekundowa reklama i potem 15-sekundowa reklama co trzy
minuty. Owszem dla mnie połączenie było "za darmo", bo płacił reklamodawca.
A że koszt minuty połączenia zarówno wtedy jak i teraz nie był kwotą o jaką
*wzrasta* koszt działania sieci przy danym połączeniu, tylko był ryczałtowo
przeliczony jako koszt stały utrzymania całej sieci + koszt zmienny
(znacznie mniejszy) zestawiania połączeń i podzielony przez średnią ilość
minut wydzwanianą przez wszystkich abonentów (no i oczywiście marzę sobie
doliczyli :D) - owszem, tak jest.

> Dlaczego niby "każda zmiana dokonana przez każdego ze 100 członków zespołu
> była automatycznie dystrybuowana do wszystkich pozostałych"? Skoro
> "programiści to banki" to po cholerę bank X ma znać historię operacji
> wszystkich pozostałych banków?

Przecież napisałem, o różnicach - nie ogarniasz więceju niż jednego zdania
na raz?

>> Różnica w zapotrzebowaniu na moc obliczeniową jest spora.
>
> W nietrafionej analogii...tak.

W trafionej, tylko jej nie rozumiesz.

> Teraz wyobraź sobie sytuacje rzeczywistą, że jest 100 banków i KIR. Każdy z
> banków ma swój serwer REST oraz KIR ma swój serwer REST z bazą operacji
> wszystkich banków. W banku numer 45 klient wykonuje przelew do banku 56.
> Klika "Wykonaj". Serwer banku 45 wysyła requesta do serwera KIR i mówi mu:
> "bank 45 rachunek AAA przelew do banku 56 rachunek BBB, kwota X". Serwer
> KIRu zapisuje to do bazy prostym INSERTEM i wykonuje requesta do serwera
> banku 56 o takiej samej treści jaką przed chwilą otrzymał. Bank 56 zapisuje
> to do bazy i wykonuje requesta do serwera KIR: "OK, potwierdzam zapis".
> Serwer KIR zapisuje w bazie, w rekordzie, który poprzednio zainsertował
> status: "Potwierdzono" i wysyła requesta do serwera banku 45: "Wykonano".
> Bank 45 zapisuje do bazy przy wykonanym przelewie: "Potwierdzono'. Koniec.
> Liczby:
> - cztery lekkie requesty RESTowe
> - 3 inserty i 3 updaty w SQLu
>
> To oczywiście pewne uproszczenie, ale tak to może działać.

Cytując Ciebie "w nietrafionym uproszczeniu... tak". Myślisz, że w takich
systemach najbardziej czasochłonne są inserty do bazy? Same cyfrowe podpisy
do tych requestów oraz ich weryfikowanie zajmuje znacznie więcej niż insert
do bazy, no ale pewnie i tak wiesz lepiej...
Czy się nie da? Oczywiście że się da, w końcu Elixirem biega około 2
miliardy transakcji rocznie, czyli nic nadzwyczajnego, niecałe 7 milionów
transakcji dziennie uwzględniając tylko dni robocze, gdyby chodziło o samo
"insert into" to byłby to detal.

Skoro się nabijasz, że w NBP (obsługującym SORBNET2) mają Odry, S/360 czy
Bosman-8, to nie, w zeszłym roku mieli sprzęt klasy Delle PowerEdge R510 i
R710 oraz IBM-y x3650 i x3950 i w samym zeszłym roku dokupili co najmniej
31 serwerów (po dwa procki 8-10 rdzeniowe każdy) - wiem, bo kumpel handluje
sprzętem i startował w przetargu zarówno na nowe serwery jak i na
serwisowanie już istniejących. Owszem, SPARC T5 (8 wątków na rdzeń co daje
128 wątków na procesor) to to nie jest, ale "insert into" na mySQL-u
powinno uciągnąć, tylko byś musiał kilka godzin w weekend poświęcić i soft
napisać (to przecież banalne, trzy requesty na krzyż i gotowe, skrypt w
perlu czy pythonie trzaśniesz i będzie :D).

Z mojej strony EOT. Uznajmy że Ty masz rację (a ja święty spokój) i
odwołuję wszystkie argumenty jakich użyłem w tym wątku.

do góry

Użytkownik Pit n...@s...lonestar.org ...

> No ale przez te 24 godziny to nie było tak, że ktoś spróbował raz, nie
> wyszło i odpuścił na 24 godziny, tylko większość próbowała cały czas (i
> wielokrotnie) "dobić się" do systemu zwiększając tylko jego obciążenie
> (zmniejszając tym samym szansę na to, że wszystko pójdzie gładko). System
> nie miał kolejkowania a kilkuset sesji równolegle nie był w stanie
> uciągnąć i poległ.

znów błąd na poziomie programu.
Mozna było to łączenie zostawić programowi i np. zaprogramować, ze jak nie
moze sie polaczyc to na nastepna próbe czeka 5-10 minut.

do góry

Użytkownik Pit n...@s...lonestar.org ...

>>>> Ale ja nie pisze jak było tylko ze wymagania nie były jakies
>>>> wielkie i nie był potrzebny jakis mega hiper system.
>>>> Potrzebny był za to w miare prosty system, ale dobrze napisany.
>>>
>>> Oczywiście że nie potrzeba jakiegoś mega hiper systemu, może nawet w
>>> tym co było wystarczyło mądrze serwer (dać mniej równoległych sesji,
>>> przez co byłyby "załatwione" szybciej i bez rozsypywania się
>>> integralności danych ze względu na wyskakujące timeouty czy "out of
>>> memory").
>>
>> cbdu.
>
> Komu? Sobie? :D

Ogólnie :)

> Przecież nie twierdziłem, że potrzebny jest
> "hipersystem"

Inni twierdzili.

>, napisałem jedynie, że nie jest to zadanie trywialne
> typu "jeden insert na każdy obwód i po sprawie" i jeśli to ma działać
> "live" (nie na zasadzie teraz coś wysyłam, a za godzinę dostaję
> potwierdzenie, że wysłałem, tylko praktycznie natychmiast, czyli w
> ciągu powiedzmy maksymalnie pół minuty) to sporo rzeczy jest do
> przemyślenia, bo "pułapki" jak najbardziej są.
>
Przychodzi mi na mysl inne, trywialne rozwiazanie.
- weryfikacja danych na poziomie programu w komisji
- wrzucenie pliku wynikowego przez ftp (to tez mogłby robic to program)
- a dalej juz serwer przerabia sobie pliki we własnym zakresie, w
odpowiedniej dla siebie predkosci.

Przeciez ten system nie musiał działać online w sensie ze od razu przy
polaczeniu dane lądowały we wspolnej bazie, prawda?

do góry

W dniu 2015-07-31 10:00, Budzik pisze:
> Użytkownik Pit n...@s...lonestar.org ...
>
>>>>> Ale ja nie pisze jak było tylko ze wymagania nie były jakies
>>>>> wielkie i nie był potrzebny jakis mega hiper system.
>>>>> Potrzebny był za to w miare prosty system, ale dobrze napisany.
>>>>
>>>> Oczywiście że nie potrzeba jakiegoś mega hiper systemu, może nawet w
>>>> tym co było wystarczyło mądrze serwer (dać mniej równoległych sesji,
>>>> przez co byłyby "załatwione" szybciej i bez rozsypywania się
>>>> integralności danych ze względu na wyskakujące timeouty czy "out of
>>>> memory").
>>>
>>> cbdu.
>>
>> Komu? Sobie? :D
>
> Ogólnie :)
>
>> Przecież nie twierdziłem, że potrzebny jest
>> "hipersystem"
>
> Inni twierdzili.

Nikt nie twierdził, że supersystem jest potrzebny, tylko wiedza jak to
zrobić i pomysły SF, które podajesz pewnie przyszły do głowy twórcom, po
weryfikacji z rzeczywistością (np z przepisami i wymogami) polegli.

>
>> , napisałem jedynie, że nie jest to zadanie trywialne
>> typu "jeden insert na każdy obwód i po sprawie" i jeśli to ma działać
>> "live" (nie na zasadzie teraz coś wysyłam, a za godzinę dostaję
>> potwierdzenie, że wysłałem, tylko praktycznie natychmiast, czyli w
>> ciągu powiedzmy maksymalnie pół minuty) to sporo rzeczy jest do
>> przemyślenia, bo "pułapki" jak najbardziej są.
>>
> Przychodzi mi na mysl inne, trywialne rozwiazanie.
> - weryfikacja danych na poziomie programu w komisji

Takk i przy zakłóceniu komunikacji, gdy nie przyjdą wszystkie dane
poprawnie żadnej kontroli, choćby sumy kontrolnej?

> - wrzucenie pliku wynikowego przez ftp (to tez mogłby robic to program)

A co z potwierdzeniem poprawności danych i akceptacją przyjęcia? Wiesz -
dopóki takiej nie ma, komisja nie może się rozejść do domu.

> - a dalej juz serwer przerabia sobie pliki we własnym zakresie, w
> odpowiedniej dla siebie predkosci.

Przecież podawane było, że to nie jest kwestia wydajności serwera, tylko
złego projektu programistycznego i na to, że system nie zadziałał
złożyło się wiele przyczyn, ale podstawowa to była taka, że tym, którzy
go tworzyli wydawało się, że wiedzą.

> Przeciez ten system nie musiał działać online w sensie ze od razu przy
> polaczeniu dane lądowały we wspolnej bazie, prawda?

Musiało być zatwierdzenie, jak później to rozwiązać, czy będzie pełne
księgowanie, czy tak jak było kiedyś w niektórych systemach bankowych,
najpierw księgowanie uproszczone, a następnie przetwarzanie (dlatego w
niektórych bankach np w nocy nie dało sie zrobić operacji kartami w
dawnych czasach, bo było tzw "przetwarzanie"), to na prawdę najmniejszy
problem. I nikt nie mówi, że mając sprzęt, który był nie dało się tego
przeprowadzić prawidłowo, ale żeby to zrobić, trzeba było mieć trochę
więcej wiedzy. A to, że rozjechały sie dane po pierwszych awariach
nasuwa mi pomysł, że i sama baza danych była zrobiona źle i dlatego
wszystko dupnęło.


--
Kaczus
http://kaczus.ppa.pl

do góry

On Fri, 31 Jul 2015 00:07:47 +0000 (UTC), Pit wrote:

> Nadal to nie jest za darmo, a że nie Ty za to płacisz, tylko inni (na
> przykład użytkownicy premium, albo muzycy chcący się wypromować czy

Dżizas... co trzeba mieć za blokadę w głowie, żeby przez sekundę ponyśleć,
że gdy piszę "za darmo" to mam na myśli koszt utrzymania! Chłopie, ogarnij
się. Oczywiście, że piszę o cenie końcowej a nie o kosztach wytworzenia i
utrzymania, to truizm. Nawet przejście 3 kroków generuje koszty
energetyczne, więc... nie zaniżaj poziomu dyskusji :-P

>> Dlaczego niby "każda zmiana dokonana przez każdego ze 100 członków zespołu
>> była automatycznie dystrybuowana do wszystkich pozostałych"? Skoro
>> "programiści to banki" to po cholerę bank X ma znać historię operacji
>> wszystkich pozostałych banków?
>
> Przecież napisałem, o różnicach - nie ogarniasz więceju niż jednego zdania
> na raz?

Możesz bronić się teraz wymyślając ad hoc inne wersje wydarzeń, ale
trzymajmy się faktów, Twoja analogia była trafiona jak porównanie kapusty
do piłki koszykowej tylko dlatego, że obie okrągłe.

>>> Różnica w zapotrzebowaniu na moc obliczeniową jest spora.
>>
>> W nietrafionej analogii...tak.
>
> W trafionej, tylko jej nie rozumiesz.

Uhm... nie tylko ja. Ile jeszcze osób musi Ci napisać, że coś w niej nie
tak, żebyś się pochylił i znalazł lepszą?

>> Teraz wyobraź sobie sytuacje rzeczywistą, że jest 100 banków i KIR. Każdy z
>> banków ma swój serwer REST oraz KIR ma swój serwer REST z bazą operacji
>> wszystkich banków. W banku numer 45 klient wykonuje przelew do banku 56.
>> Klika "Wykonaj". Serwer banku 45 wysyła requesta do serwera KIR i mówi mu:
>> "bank 45 rachunek AAA przelew do banku 56 rachunek BBB, kwota X". Serwer
>> KIRu zapisuje to do bazy prostym INSERTEM i wykonuje requesta do serwera
>> banku 56 o takiej samej treści jaką przed chwilą otrzymał. Bank 56 zapisuje
>> to do bazy i wykonuje requesta do serwera KIR: "OK, potwierdzam zapis".
>> Serwer KIR zapisuje w bazie, w rekordzie, który poprzednio zainsertował
>> status: "Potwierdzono" i wysyła requesta do serwera banku 45: "Wykonano".
>> Bank 45 zapisuje do bazy przy wykonanym przelewie: "Potwierdzono'. Koniec.
>> Liczby:
>> - cztery lekkie requesty RESTowe
>> - 3 inserty i 3 updaty w SQLu
>>
>> To oczywiście pewne uproszczenie, ale tak to może działać.
>
> Cytując Ciebie "w nietrafionym uproszczeniu... tak". Myślisz, że w takich
> systemach najbardziej czasochłonne są inserty do bazy? Same cyfrowe podpisy
> do tych requestów oraz ich weryfikowanie zajmuje znacznie więcej niż insert
> do bazy, no ale pewnie i tak wiesz lepiej...

Po pierwsze napisałem, że to wersja uproszczona. Po drugie weryfikacja może
sobie trwać, to się nie musi odbywać w milisekundach i w real timie. Klient
klika "Wykonaj" i robi swoje, a system w tle dopełnia reszty, może to
zakolejkować i zrobić, gdy będzie miał zasoby.

> Czy się nie da? Oczywiście że się da, w końcu Elixirem biega około 2
> miliardy transakcji rocznie, czyli nic nadzwyczajnego, niecałe 7 milionów
> transakcji dziennie uwzględniając tylko dni robocze, gdyby chodziło o samo
> "insert into" to byłby to detal.

To nadal jest detal. Jeśli sama obsługa komunikacji i baz to detal, a już
obsługa uwierzytelniania i autoryzacji to kosmiczny wyczyn to ...cytując
Ciebie... nie mam więcej pytań ;-)

> Skoro się nabijasz, że w NBP (obsługującym SORBNET2) mają Odry, S/360 czy

Ani słowem nie nabijałem się ze sprzętu w NBP, nie mam pojęcia co tam mają.

> Bosman-8, to nie, w zeszłym roku mieli sprzęt klasy Delle PowerEdge R510 i
> R710 oraz IBM-y x3650 i x3950 i w samym zeszłym roku dokupili co najmniej
> 31 serwerów (po dwa procki 8-10 rdzeniowe każdy) - wiem, bo kumpel handluje
> sprzętem i startował w przetargu zarówno na nowe serwery jak i na
> serwisowanie już istniejących. Owszem, SPARC T5 (8 wątków na rdzeń co daje
> 128 wątków na procesor) to to nie jest, ale "insert into" na mySQL-u
> powinno uciągnąć, tylko byś musiał kilka godzin w weekend poświęcić i soft
> napisać (to przecież banalne, trzy requesty na krzyż i gotowe, skrypt w
> perlu czy pythonie trzaśniesz i będzie :D).

Wyobraź sobie, że nie w weekend, ale na etacie "trzaskam" serwery RESTowe i
zapieprzają aż miło. Mają też autoryzację i uwierzytelnianie, choć bez
podpisów cyfrowych, nie ma takiej potrzeby. No i nie w Pythonie, ani innym
języku skryptowym, są kompilowane do kodu natywnego maszyny.

> Z mojej strony EOT. Uznajmy że Ty masz rację (a ja święty spokój) i
> odwołuję wszystkie argumenty jakich użyłem w tym wątku.

No uciekaj jeśli chcesz, a z racją jest jak z dupą... wiadomo.

--
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

do góry

Dnia 31.07.2015 Budzik <b...@p...o.n.e.t.pl.nie.spam.oj> napisał/a:
> Przychodzi mi na mysl inne, trywialne rozwiazanie.
> - weryfikacja danych na poziomie programu w komisji

Ale to musi być zgodne z ustawą "Kodeks Wyborczy" - można zrobić wewnętrzną
walidację, ale weryfikacja poprawności protokołu musi być zewnętrzna i
wynik wyborów w obwodzie jest "znany" dopiero wtedy, jeśli wersja z obwodu
i wersja z "piętra wyżej" są zgodne. Tam chyba i tak był spory luz, bo te
wszystkie dane nie musiały spełniać kryteriów dokumentu elektronicznego
(wszystko i tak było docelowo drukowane i podpisywane), więc można sobie
było pozwolić na wiele uproszczeń.

do góry

szemrany wrote:


> Po pierwsze napisałem, że to wersja uproszczona. Po drugie weryfikacja
> może sobie trwać, to się nie musi odbywać w milisekundach i w real timie.
> Klient klika "Wykonaj" i robi swoje, a system w tle dopełnia reszty, może
> to zakolejkować i zrobić, gdy będzie miał zasoby.

IMHO to tak nie moze dzialac, bo system musi odpowiedziec natychmiast
"Przelew poszedl" albo "przelew odrzucony". Kasa musi sie zgadzac w
systemie.

RW

do góry

Dnia 31.07.2015 szemrany <s...@o...off> napisał/a:
>> Cytując Ciebie "w nietrafionym uproszczeniu... tak". Myślisz, że w takich
>> systemach najbardziej czasochłonne są inserty do bazy? Same cyfrowe podpisy
>> do tych requestów oraz ich weryfikowanie zajmuje znacznie więcej niż insert
>> do bazy, no ale pewnie i tak wiesz lepiej...
>
> Po pierwsze napisałem, że to wersja uproszczona. Po drugie weryfikacja może
> sobie trwać, to się nie musi odbywać w milisekundach i w real timie. Klient
> klika "Wykonaj" i robi swoje, a system w tle dopełnia reszty, może to
> zakolejkować i zrobić, gdy będzie miał zasoby.

Przykład trafiony jak to Twoje porównanie z "kapustą". Nie, system nie może
sobie najpierw dać Ci kasy na konto, a potem sobie w wolnym czasie
zaksięgować. O ile sesja elixir to jest JEDEN dokumenht elektroniczny
zawierający dziesiątki tysięcy pozycji (weryfikacje podpisów itd. robi się
raz), o tyle RTGS to dziesiątki tysięcy jednopozycyjnych dokumentów
elektronicznych (z których każdy musi zostać po jednej stronie podpisany a
po drugiej zweryfikowany). Sam "insert into" to detal, jak się kasa pojawia
na koncie, to znaczy, że wszystkie formalności zostały już załatwione.
Te wszystkie BlueCashe korzystają z tego, że banki mają uprawnienia
notarialne i poświadczają swoim podpisem elektronicznym dokumenty robione
przez innych (nawet moje czy Twoje przelewy - nasze hasła czy PIN-y z
tokenów to żaden podpis, bank poświadcza zlecenie za nas). A to tylko jeden
aspekt - ważność dokumentu (podpowiem - nie, nie wystarczy zrobić tego po
SSL-u i podpisać połączenie, musi być podpisany każdy dokument, bo ten
dokument wraz z podpisem musi być przechowywany przez ileś tam lat i musi
być weryfikowalny "sam w sobie", na przykład jeśli się go zgra na
przysłowiową dyskietkę).

>> Czy się nie da? Oczywiście że się da, w końcu Elixirem biega około 2
>> miliardy transakcji rocznie, czyli nic nadzwyczajnego, niecałe 7 milionów
>> transakcji dziennie uwzględniając tylko dni robocze, gdyby chodziło o samo
>> "insert into" to byłby to detal.
>
> To nadal jest detal. Jeśli sama obsługa komunikacji i baz to detal, a już
> obsługa uwierzytelniania i autoryzacji to kosmiczny wyczyn to ...cytując
> Ciebie... nie mam więcej pytań ;-)

Pisałem nie o uwierzytelnianiu i autoryzacji, tylko o podpisie
elektronicznym, autoryzacja i uwierzytelnianie to osobna sprawa. Skoro nie
masz więcej pytań, to dziękuję za uwagę ;)


> Wyobraź sobie, że nie w weekend, ale na etacie "trzaskam" serwery RESTowe i
> zapieprzają aż miło. Mają też autoryzację i uwierzytelnianie, choć bez
> podpisów cyfrowych, nie ma takiej potrzeby. No i nie w Pythonie, ani innym
> języku skryptowym, są kompilowane do kodu natywnego maszyny.

Twoje serwery nie obsługują dokumentów elektronicznych (w rozumieniu
prawnym), a przynajmniej tak zgaduję po tym co pisałeś (komputery
wspomagają przetwarzanie danych, ale jak trzeba formalnie, to jest papier).
Owszem, da się wszystko zrobić, ale aby zapewnić szybkie przelewy, to nie
wystarczy zmodernizować to, co jest w NBP, ale też wszystkie banki w tym
jakieś banki spółdzielcze w koziej wólce, bo i tak będziesz narzekał
"kurwa, miało być w 5 minut a kasy na koncie nie ma", BlueCash może sobie
wybierać z jakimi bankami współpracuje a z jakimi nie, NBP czy KIR nie ma
tego komfortu, dlatego jest jeszcze utrzymywany Elixir, bo takie "kozie
wólki" nawet ExpressElixirów (za które KIR nie pobiera opłat) nie
obsługują, a co dopiero RTGS. Inna rzecz, że nawet jeśli banki mają jakąś
funkcjonalność, to muszą czymś odróżnić konta "darmowe dla szaraka" od kont
płatnych dla bardziej zamożnych czy kont korporacyjnych i różnica jest na
przykład taka, że w "darmowym koncie" płacisz ekstra za wszystko oprócz
elixirów i karty typu VisaElectron, a w koncie płatnym nie płacisz ekstra
za "ficzery". To jak z "darmowymi minutami" - jak chcesz mieć darmowy
abonament (na przykład pre-paid) to płacisz za to co wydzwonisz, a jak
chcesz mieć "nielimitowane rozmowy" to nie masz darmowego abonamentu (albo
jest system mieszany, do jakiegoś momentu płacisz za minuty, a jak suma
płatności za minuty osiągnie wielkość "abonamentu" to system traktuje to
jak abonament).

>> Z mojej strony EOT. Uznajmy że Ty masz rację (a ja święty spokój) i
>> odwołuję wszystkie argumenty jakich użyłem w tym wątku.
>
> No uciekaj jeśli chcesz, a z racją jest jak z dupą... wiadomo.

No wiadomo, to tak jak z prawdą wg Tischnera

do góry

On Fri, 31 Jul 2015 14:04:24 +0100, RW wrote:

>> Po pierwsze napisałem, że to wersja uproszczona. Po drugie weryfikacja
>> może sobie trwać, to się nie musi odbywać w milisekundach i w real timie.
>> Klient klika "Wykonaj" i robi swoje, a system w tle dopełnia reszty, może
>> to zakolejkować i zrobić, gdy będzie miał zasoby.
>
> IMHO to tak nie moze dzialac, bo system musi odpowiedziec natychmiast
> "Przelew poszedl" albo "przelew odrzucony". Kasa musi sie zgadzac w
> systemie.

Nie zrozumiałeś. User zajmuje się swoimi sprawami, a system bankowy zajmuje
się integralnością danych czyli będzie dbał o prawidłowe zakończenie
transakcji. A jeśli mimo wszystko będzie coś nie tak to w historii pojawi
się obok przelewu adnotacja: odrzucono.

--
howgh
szemrany
"Trzeba z żywymi naprzód iść, po życie sięgać nowe,
a nie w uwiędłych laurów liść z uporem stroić głowę"

do góry